I guess I'd still prefer we do <artifactId>-<version> for the tag
names as maven does.
There's also a small catch in that the directories we've been using
are not the artifactIds.
-David
On Aug 16, 2006, at 2:06 PM, Jason Dillon wrote:
Does not really look like anything needs to be moved. The only
things (other than svn ci) would be svn mkdir for each spec in
tags, since mvn release will not make that tree... as in:
<snip>
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-activation
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-commonj
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-corba
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-corba-2.3
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-corba-3.0
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-j2ee
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-j2ee-connector
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-j2ee-deployment
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-j2ee-jacc
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-j2ee-management
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-javamail-1.3.1
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-javamail-1.4
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-jaxr
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-jaxrpc
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-jms
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-jsp
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-jta
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-qname
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-saaj
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-servlet-2.4
svn mkdir https://svn.apache.org/repos/asf/geronimo/specs/tags/
geronimo-spec-servlet-2.5
</snip>
I think everything else is just pom updates.
--jason
On Aug 16, 2006, at 1:50 PM, David Jencks wrote:
On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote:
I have always been in favor of dropping any uber-jars. They
cause more problems then they are worth.
As for RTC... I am not so sure that this applies really. Its not
going to surprise anyone, its not adding any new code... just
fixing up the poms and moving a few bits around in svn.
But, I can jump though the RTC hoop if that is what the PMC
wants... I think its a waste of time... mostly mine.
This is obviously not something that a patch will work for in
terms of comprehension and probably function.
If we need RTC I think that supplying the svn mv commands is what
we'd vote on.
I think we have voted on the desired outcome and that is
sufficient, but I won't push the issue.
Jason, how hard would it be to come up with the svn commands you'd
use, and what else is there to do?
thanks
david jencks
--jason
On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
What is the status on 1.1.1 wrt this change? Can I go ahead
and make these changes?
My reading of Matt's note (which I agree with) is that you
should wait until 1.1.1 has been shipped (unless 1.1.1 runs into
an extended delay in releasing due to administrative matters).
I think this change should follow the RTC process. This is not a
bug fix, not a doc change, etc. It's updating svn and changing
the way we deliver specs -- my read is that it falls under RTC.
You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's
currently versioned using the top-level pom version. I assume
you plan on adding a geronimoSpecsJ2eeVersion?
Your process for updating the jms spec would be:
cd specs/geronimo-spec-jms
mvn release
cd ../geronimo-spec-j2ee
mvn release
I'm not so sure that this is any better than we have now... I
see two options:
1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't
changed) and all have the same version...
--kevan
--jason
On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to
release an updated version of the J2EE_JAAC specs. I am
waiting for feedback from Geir on some licensing issues as
well as a TCK run that Kevan is doing. That said I'd prefer
to wait until the we cut the 1.1.1 release. If it looks like
its going to be delayed due to the licensing concerns then we
should do this straight away next week.
Since this isn't a code change I agree with Jason's comments
on no review required. Lazy consensus is appropriate here.
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
