[Building Sakai] Maven Version Numbers

[Matthew Jones]

Agreed, this issue (MNG-624) keeps getting bumped. I've been watching it for
2 years now and there's not much progress on it. The best solutions are
either what gradebook 2 does where it does a sed replacement on the poms
https://source.sakaiproject.org/contrib/gradebook2/trunk/setSakaiVersion.sh

Or something better would be to use a real xml replacement, either
xmlstarlet as a shell tool or xalan (as you know someone would have java
available). Part of the umich build process does a xalan replacement of all
of the parent versions in all tools before building. The transforms are in
this XSL file. [1]

I was hoping the maven versions plugin [2] might help to avoid some of these
transforms but I couldn't get any of the goals to work as I needed, even the
one that says "update-parent" [3] didn't quite do what I needed. :(

[1]
https://source.sakaiproject.org/svn/msub/umich.edu/ctools/ctools-buildscripts/groovybuild/xslt/fixversion.xslt
[2] http://mojo.codehaus.org/versions-maven-plugin/
[3]
http://mojo.codehaus.org/versions-maven-plugin/examples/update-parent.html

-Matthew

On Wed, Feb 16, 2011 at 12:42 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

> >  In spite of
> > substantial Maven documentation to the contrary, the property reference
> > isn't resolved.
>
>
> What Maven documentation suggests otherwise?  Variable substitutions in
> parent poms, although demanded by many, has not been implemented in Maven 2x
> or 3x (as of yet).
>
> See the long discussion in the yet unresolved MNG-624 as well as related
> MNG tickets.
>
> http://jira.codehaus.org/browse/MNG-624
>
>
> Cheers,
>
> Anth
>
>
>
>
> On Feb 16, 2011, at 11:37 AM, Mark Norton wrote:
>
> > I have a Sakai tool that I maintain for SoftChalk called lbgateway.  It
> > has two POMs that follow the general Sakai conventions.  My problem is
> > with the parent references.  The version number is hard coded to the
> > current version of Sakai, currently 2.7.1.  Since this version number is
> > hard coded in the POMs, it means that I have to maintain separate tagged
> > builds for 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.7.0, and 2.7.1 (not to mention
> > the upcoming 2.8.0 release).  Every time I make a minor bug fix to the
> > code, I have to update six (!) tagged releases just because the version
> > number is hard coded.
> >
> > Since the parent element in the POM refers to the Sakai master POM, I
> > don't really understand why the current Sakai version can't be defined
> > there.  Instead, it is hard-wired into ALL Sakai tools.
> >
> > I have tried setting a property in settings.xml along the lines of
> > "<softchalk.sakai.version>2.7.1</softchalk.sakai.version> and
> > referencing it in the POMs as ${softchalk.sakai.version}.  In spite of
> > substantial Maven documentation to the contrary, the property reference
> > isn't resolved.
> >
> > So I ask you, fellow Sakaigers, is this fixable?  Is there a way to
> > centrally declare the current Sakai version so that I don't have to
> > maintain a half dozen tagged versions of a tool?  Am I crazy to want
> this?
> >
> > - Mark Norton
> >
> >
> > _______________________________________________
> > sakai-dev mailing list
> > sakai-dev at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >
> > TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
> >
> >
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110216/abee5c30/attachment.html