[mapguide-internals] RE: [fdo-users] FDO 3.3.2 RC1 Posted

Robert Fortin robert.fortin at autodesk.com
Thu Oct 9 17:17:45 EDT 2008


Effectively, you would need a mergemodule for FDO and each provider and a MSI that wraps this mergemodules together. Pretty much what we had before MG went back to just using the binaries.

I think you will have to convince MapGuide to go back to the merge module. I think they ran into issue with the integrate from build to build.

RF

From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, October 09, 2008 5:10 PM
To: FDO Users Mail List; MapGuide Internals Mail List
Subject: RE: [fdo-users] FDO 3.3.2 RC1 Posted

(copying MapGuide-internals)

Robert, re:

 [RF] FDO use to have msi for the FDO sdk.  It did include a merge module for each provider with a custom action to register the provider (and populate the providers.xml file).  Application like MapGuide prefered to use the zipped version of the sdk (the one you can download), extract the binary files, create their own providers.xml and repackage it as part of their own install.  So we kind of abandon the opensource version of the msi.  If there is a need, we would have to look into how it can be resurrected.

I think that if MapGuide moves towards a Visual Studio-based setup process, it would be useful to include merge modules for FDO and the individual providers.  Ideally, this would only be maintained in one place (the FDO project) rather than in both.  This would (eventually?) allow the user to choose which providers to install as part of the setup process.  I think that this would mean that the FDO MSI setup project would have to be duplicated as a merge module though?  Or could the FDO MSI installer be re-architected as a thin wrapper around FDO core and provider merge modules?

Jason


More information about the mapguide-internals mailing list