geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Samples release process
Date Wed, 21 May 2008 14:57:49 GMT
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.
[ERROR] BUILD ERROR
[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.

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.

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:
- http://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.1
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:
- http://svn.apache.org/repos/asf/geronimo/samples/tags/2.1.0 (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).

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.

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





Mime
View raw message