Makes sense to me too. +1
Joe
Jason Dillon wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own trunk
+branches+tags...
I have been thinking about this for a while, and with the recent desire
to split off more modules from geronimo/trunk I've been pondering it
even more. What I have come to believe is that spitting up spec
modules into their own trunk+branches+tags is probably not the best
direction for us to head in.
I believe that all of our specs can, and should, share one trunk... and
still have each module specify its own version. This is very similar
to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The top-
level pom has a version too, which is independent and is only changed
when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in its
own trunk, you would need to svn co each one, then mvn install in each
tree, which is a pain.
We also almost never branch specs, they just keep chugging along, only
really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/<artifactId>
specs/tags/<artifactId>/<version>
And if needed:
specs/branches/<artifactId>/<name>
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we can
set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$ {pom.artifactId}
When released, the plugin will svn cp just the module's directory into
a directory under tags, so it will be easy to see what the released
versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more difficult
for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which isn't
that major, is that the properties which live in the root pom that
control the versions need to be removed... or rather moved back to the
<version> element of the respective pom.
Comments?
--jason
