[mapguide-internals] MapGuide Open Source 2.1 - where isthecontinuous integration system ????

[Jackie C. Ng]

What about using NSIS? Was it not the installer technology of choice you
initially had in mind?

- Jackie


JasonBirch wrote:
> 
> Trevor, all,
> 
> I spend a bunch of time playing with Visual Studio setup packages, and
> was pretty underwhelmed.  Seems like a good solution for something
> small, but not for what I would eventually want from the MapGuide
> installer.
> 
> I also spent a few hours familiarizing myself with WiX, which seems to
> be a pretty decent solution.  When combined with something like a
> modified version of Paraffin (allows automated import of file references
> given a source directory), I think it would meet our needs quite
> handily, and allow room in the future for more advanced stuff.
> 
> If anyone's interested, my WiX 3 VS2008 project is available here:
> 
> http://www.jasonbirch.com/temp/mginstall/MgInstaller.zip 
> 
> And the MSI I created while goofing around (it basically just installs
> FDO) is here:
> 
> http://www.jasonbirch.com/temp/mginstall/NotMapGuideOpenSource-0.0.1.msi
> (9.5MB)
> 
> 
> WiX (Version 3 is in beta but already far better than 2):
> 
> http://wix.sourceforge.net/
> 
> Paraffin (we'd want to update for WiX3):
> 
> http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/07/11/paraffin-
> 1-04-a-new-switch-and-easier-updates.aspx
> 
> Jason
> 
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor
> Wekel
> Sent: Thursday, November 13, 2008 15:48
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] MapGuide Open Source 2.1 - where
> isthecontinuous integration system ????
> 
> 
> Perhaps Tim can chime in here but there may be a few holes with simply
> using the existing build/install scripts for open source:
> 
> Autodesk uses BuildForge internally and OsGeo is using BuildBot.  The
> existing build scripts may not be BuildBot compatible.   The open source
> community may need to adapt/modify the existing BuildForge scripts to
> work with BuildBot.
> 
> The Windows installers for open source use InstallShield.  Unless
> someone wants to purchase one or more InstallShield licenses, we will
> not be able to use the existing open source installers.  I have
> suggested using Visual Studio deployment projects as an alternative.  I
> took a brief look at the Visual Studio deployment projects a while ago
> and they seemed to have enough features.
> 
> Tim already has RPM configuration files available for RedHat Linux.  It
> may be possible to adapt these for use with other distributions.
> 
> 
> If we want to get the open source builds moving on Windows, here is an
> initial set of tasks:
> 
> 1.  Set up a publically accessible Windows build machine with Visual
> Studio installed
> 
> I should be able to do this by early next week.  However, there is a
> restriction.  Visual Studio is licensed by user so maintainers should
> purchase their own copy of Visual Studio Standard (or higher).  Ideally
> we should use the "build" machine as a build machine and not an
> installer development box.
> 
> http://download.microsoft.com/documents/useterms/Visual%20Studio_2008%20
> Standard%20Edition_English_4c240268-8ee9-4cf3-96cf-3bd5ef02a81f.pdf
> Item 1 b) specifically states "per user"
> 
> 2.  Obtain the current open source Windows build scripts from Tim and
> investigate whether they are  appropriate for BuildBot.
> 
> 3.  Start looking at installer technology for the Windows builds.  The
> Server install will be easier than the Web Extensions install.  Visual
> Studio may be sufficient.  InstallShield would be a more expensive
> option but is guaranteed to work.  As far as I know, InstallShield is
> also a user based license.
> 
> Anyone interested in looking into items 2 or 3?  We can add additional
> items for the Linux distros (cmake, rpm config files, etc) but I will
> not have time to set up multiple VMs by next week.  I suspect the
> community would prefer to see the Windows installs working before we
> tackle the various Linux distros.
> 
> Thanks,
> Trevor
> 
> 
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org
> [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom Fukushima
> Sent: Thursday, November 13, 2008 4:03 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] MapGuide Open Source 2.1 - where is
> thecontinuous integration system ????
> 
> Hi Jason,
> 
> Comments inline...
> 
> Tom
> 
> 
> 
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
> Birch
> Sent: Thursday, November 13, 2008 3:20 PM
> To: mapguide-internals at lists.osgeo.org
> Subject: Re: [mapguide-internals] MapGuide Open Source 2.1 - where is
> thecontinuous integration system ????
> 
> Tom,
> 
> We should be careful to distinguish between continuous builds (a
> development tool) and packaging (a user service). IMHO, packaging is a
> much more critical issue at this point.
>>>> Continuous builds or builds of some sort are required for the
> packaging.  The two are required and if we are going to do builds, we
> should just do it right.  What's to be careful about here, let's set out
> what needs to be done (RFC), and do it.
> 
> 
> Autodesk's resourcing issues had come up a couple times, but the
> potential disavowal of responsibility for packaging is news to me, and I
> would imagine most of the users on the public mailing lists.
>>>> The build team here does all parts of the build and this includes
> packaging.
> 
> I think that by keeping the installer process closed source, Autodesk
> essentially committed to maintain the open source installer packages
> right from the start. Without installers you may have an open source
> application, but no chance of building a project/community.
>>>> There is nothing being kept intentionally under wraps here.  Tim has
> always told me he's ready to give the scripts to anyone who needs them.
> 
> The mgos community may be strong enough to take on the challenge at this
> point, but I feel that some support from Autodesk (even if its just a
> list of files, registry keys, conf file setting, permissions, etc) is
> critical to moving the packaging process out as a community
> responsibility. I don't have the visual studio expertise to create the
> setup project, but I would be happy to take on the role of package
> creation for new MGOS releases if I can get some help setting this up.
>>>> I would hope the community can take this on.  It's been over two
> years since our first release.  Scripts are available from Autodesk.
> 
> I don't know what to do about Linux packaging.  Without the adoption of
> the cmake build process, I have absolutely no interest in even looking
> at this.
>>>> We have never packaged for Linux.  We've only provided the source
> tar package for that particular release.  It would be good to address
> this as well.
> 
> Jason
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> 
> 


-----
http://themapguyde.blogspot.com

http://www.linkedin.com/in/jackieng
-- 
View this message in context: http://www.nabble.com/Re%3A-MapGuide-Open-Source-2.1---where-is-thecontinuous-integration-system------tp20490798p20511558.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.