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.
[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.
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
genesis).
-DautoVersionSubmodules=true
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).
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
goal.
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.
thanks
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
