geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Samples release process
Date Wed, 21 May 2008 15:19:23 GMT

On May 21, 2008, at 10:57 AM, Joe Bohn wrote:

> I've been stuck attempting to use the maven-release-plugin for  
> samples for a few reasons.  I would like go ahead and create a  
> branch for this release which will later be converted to a tag (the  
> old fashioned way). Are there any strong objects? (Note: I'm asking  
> because of this sentence in our release process doc - "...most  
> smaller projects such as specs, plugins, components, and most likely  
> tools should avoid the complexity of branches unless clearly  
> necessary and agreed upon." )
> Here are the problems that I'm having using the release-plugin/ 
> process:
> 1) There is a version property defined in the root pom to match the  
> release version.  The maven-release-plugin will not change this  
> version property (just the version element in the root pom) during  
> mvn release:prepare
> I attempted to remove the version property but it appears this is  
> used to generate the directory to scan by the jasper builder as I  
> get the following error when I attempt to remove it.
> [INFO]  
> ------------------------------------------------------------------------
> [INFO] Could not scan directory for TLD files: jar:file:/Users/bohn/ 
> geronimo-samples-2.1/samples/CustomerService/CustomerService-jetty/ 
> target/repository/org/apache/geronimo/samples/CustomerService-jetty/$ 
> {version}/CustomerService-jetty-${version}.car/CustomerService- 
> ejb-2.1-SNAPSHOT.jar!/META-INF Illegal character in path at index  
> 153: file:/Users/bohn/geronimo-samples-2.1/samples/CustomerService/ 
> CustomerService-jetty/target/repository/org/apache/geronimo/samples/ 
> CustomerService-jetty/${version}/CustomerService-jetty-$ 
> {version}.car/CustomerService-ejb-2.1-SNAPSHOT.jar
> Attempting to change this version property manually prior to release  
> didn't work either.  Apparently, the maven-release does a build  
> prior to the svn changes (which fails with a manual change) and  
> after the svn changes (which fails without the manual change).
> BTW, we have this same version property defined in the server root  
> pom.

This is a problem we'll have to solve to release the server with the  
release plugin.  I thought I'd dealt with it successfully in the  
apacheds plugin release but maybe not....
> 2)  When using the maven-release-plugin I have to specify the  
> release and the new snapshot version.  The release default is fine  
> because we are currently using 2.1-SNAPSHOT and so the release will  
> be 2.1. However, I must manually specify the development release to  
> 2.1.1-SNAPSHOT or it will default to 2.2-SNAPSHOT.  This isn't a big  
> problem but it is annoying (especially since I have to enter that  
> value 78 times ... once for each artifact).  Newer versions of the  
> maven-release-plugin have parms to override these versions on the  
> command line but the version included in genesis 1.4 does not.

I think there's a configuration setting so you only have to specify it  
once.  You can set this on the command line although I think its  
better to include in the samples root pom (or the next version of  
> 3) This isn't necessary a problem but it doesn't seem right to me.   
> When The scm entries are updated for a tag with the name:
> -
> I understand why this based upon the release-plugin structure.   
> However the name doesn't seem intuitive to me.  I think a structure  
> that matches our server structure makes much more sense.  So I would  
> prefer:
> - (with  
> or without the .0)
> I think this makes much more sense and more clearly matches the  
> samples to the server (and we indicated on earlier threads that we  
> wanted to keep these in sync).

While it isn't what we've been doing by hand I am 100% in favor of  
following maven default behavior unless it breaks stuff.  We don't  
need to look different from everyone else.

> 4) I'm becoming more and more of the opinion that we should merge  
> the samples svn back into the server svn.  I see little advantage in  
> keeping these independent and a lot of problems in doing so.  If I  
> can convince folks that is the right thing to do then it doesn't  
> make much sense to get the samples releasing with the maven-release- 
> plugin while the server is still released manually.
> Some reasons I think the samples should be merged back into the  
> server svn.
> - The samples are tied to a particular server release.
> - It's important to have samples available ASAP with a server  
> release. Tying these together would ensure that they are available  
> in conjunction with the server release (you can't do any better than  
> that).
> - The samples are versioned to match the server and this would make  
> it a no-brainer to keep them in sync.
> - Samples could take advantage of the dependency management in  
> server root pom to ensure that everything is in sync with the  
> server.  As it stands now dependency versions for samples are spread  
> across numerous poms and managed independently from the server.
> - We have had 0 success to date releasing samples independently of  
> the server.

I don't buy this.  IMO we should be working hard so that samples don't  
need to be updated and released for every server release.  I think we  
also agreed that our long term direction should be that the server  
plugins are generally built and released independently of a server.   
Adding more stuff to the giant monolithic server build is against this  

One thing that might help here is to specify includeVersion false in  
the car-maven-plugin configuration.  We'd have to see if the plugins  
still worked :-)

I'll take a look and see if I can figure out what is going on with the  
${version} property.

david jencks

> Regarding #4 ... I would get 2.1 samples and 2.1.1 samples released  
> independently and then suggest we merge the samples under the server  
> svn in branches/2.1 and trunk.  We don't need to decide #4 right  
> away since we still have to get 2.1 & possibly 2.1.1 out the door.   
> The only advantage I can think of in keeping them independent is the  
> ability to build samples without building the server but as I  
> mentioned in another post I don't believe this is possible anyway at  
> the moment.
> Joe

View raw message