Re: Organization and versioning of specs; a new proposal
I'm trying to motivate to writing this... :-\
--jason
On Aug 16, 2006, at 7:41 PM, David Blevins wrote:
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.
I read this as more of a policy discussion as the topic is really,
"how do we want to layout specs now and in the future and how do we
branch and tag them on release."
Let's do like we did on this thread: http://marc.theaimsgroup.com/?
l=geronimo-dev&m=115094116905426&w=4
In other words, create a new version of the proposal that's more
detailed and incorporates the feedback from the original, then put
it up for a vote.
Jason, you want the honors?
-David
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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On Aug 17, 2006, at 11:10 AM, Alan D. Cabrera wrote: David Blevins wrote: Ok, let's go with "specs/tags/-" This is my preference as well. It is easy enough to change later if/when the top-level tags dir becomes unwieldy... so I am fine with this. --jason
Re: Organization and versioning of specs; a new proposal
David Blevins wrote: On Aug 16, 2006, at 5:16 PM, Jason Dillon wrote: On Aug 16, 2006, at 4:38 PM, David Blevins wrote: On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do - for the tag names as maven does. I'm planning on putting - under / but m2 handles this, all it needs it the root to exist. I see. When I suggested "specs/tags/-" I hadn't noticed you expand that to "specs/tags//-" Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. Maybe... I don't care either way. Ok, let's go with "specs/tags/-" This is my preference as well. Regards, Alan
Re: Organization and versioning of specs; a new proposal
I'm ok with dropping it.
-dain
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.
--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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 5:16 PM, Jason Dillon wrote: On Aug 16, 2006, at 4:38 PM, David Blevins wrote: On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do - for the tag names as maven does. I'm planning on putting - under / but m2 handles this, all it needs it the root to exist. I see. When I suggested "specs/tags/-" I hadn't noticed you expand that to "specs/tags// -" Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. Maybe... I don't care either way. Ok, let's go with "specs/tags/-" Here's what I mean: $ grep -A 3 modelVersion */pom.xml | grep artifactId geronimo-spec-activation/pom.xml- geronimo- activation_1.0.2_spec geronimo-spec-commonj/pom.xml- geronimo- commonj_1.1_spec [...] geronimo-spec-servlet-2.4/pom.xml- geronimo- servlet_2.4_spec geronimo-spec-servlet-2.5/pom.xml- geronimo- servlet_2.5_spec Ahh... well that will need to get fixed for sure. The artifactId needs to be the same as the directory name to take advantage of maven's ability to autoconfigure somethings. If they are not in sync, then we end up with extra config to put them in the right place... which is uneeded IMO. I agree. -David --jason
Re: Organization and versioning of specs; a new proposal
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.
I read this as more of a policy discussion as the topic is really,
"how do we want to layout specs now and in the future and how do we
branch and tag them on release."
Let's do like we did on this thread: http://marc.theaimsgroup.com/?
l=geronimo-dev&m=115094116905426&w=4
In other words, create a new version of the proposal that's more
detailed and incorporates the feedback from the original, then put it
up for a vote.
Jason, you want the honors?
-David
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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 4:38 PM, David Blevins wrote: On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do - for the tag names as maven does. I'm planning on putting - under / but m2 handles this, all it needs it the root to exist. I see. When I suggested "specs/tags/-" I hadn't noticed you expand that to "specs/tags// -" Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. Maybe... I don't care either way. Here's what I mean: $ grep -A 3 modelVersion */pom.xml | grep artifactId geronimo-spec-activation/pom.xml- geronimo- activation_1.0.2_spec geronimo-spec-commonj/pom.xml- geronimo- commonj_1.1_spec geronimo-spec-corba-2.3/pom.xml- geronimo- corba_2.3_spec geronimo-spec-corba-3.0/pom.xml- geronimo- corba_3.0_spec geronimo-spec-corba/pom.xml- geronimo-spec-corbaartifactId> geronimo-spec-ejb/pom.xml- geronimo-ejb_2.1_specartifactId> geronimo-spec-j2ee-connector/pom.xml- geronimo-j2ee- connector_1.5_spec geronimo-spec-j2ee-deployment/pom.xml- geronimo-j2ee- deployment_1.1_spec geronimo-spec-j2ee-jacc/pom.xml- geronimo-j2ee- jacc_1.0_spec geronimo-spec-j2ee-management/pom.xml- geronimo-j2ee- management_1.0_spec geronimo-spec-j2ee/pom.xml- geronimo-j2ee_1.4_specartifactId> geronimo-spec-javamail-1.3.1/pom.xml- geronimo- javamail_1.3.1_spec geronimo-spec-javamail-1.4/pom.xml- geronimo- javamail_1.4_spec geronimo-spec-jaxr/pom.xml- geronimo-jaxr_1.0_specartifactId> geronimo-spec-jaxrpc/pom.xml- geronimo- jaxrpc_1.1_spec geronimo-spec-jms/pom.xml- geronimo-jms_1.1_specartifactId> geronimo-spec-jsp/pom.xml- geronimo-jsp_2.0_specartifactId> geronimo-spec-jta/pom.xml- geronimo-jta_1.0.1B_specartifactId> geronimo-spec-qname/pom.xml- geronimo-qname_1.1_specartifactId> geronimo-spec-saaj/pom.xml- geronimo-saaj_1.1_specartifactId> geronimo-spec-servlet-2.4/pom.xml- geronimo- servlet_2.4_spec geronimo-spec-servlet-2.5/pom.xml- geronimo- servlet_2.5_spec Ahh... well that will need to get fixed for sure. The artifactId needs to be the same as the directory name to take advantage of maven's ability to autoconfigure somethings. If they are not in sync, then we end up with extra config to put them in the right place... which is uneeded IMO. --jason
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do - for the tag names as maven does. I'm planning on putting - under / but m2 handles this, all it needs it the root to exist. I see. When I suggested "specs/tags/-" I hadn't noticed you expand that to "specs/tags//- " Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. There's also a small catch in that the directories we've been using are not the artifactIds. I don't understand... :-\ Here's what I mean: $ grep -A 3 modelVersion */pom.xml | grep artifactId geronimo-spec-activation/pom.xml- geronimo- activation_1.0.2_spec geronimo-spec-commonj/pom.xml- geronimo- commonj_1.1_spec geronimo-spec-corba-2.3/pom.xml- geronimo- corba_2.3_spec geronimo-spec-corba-3.0/pom.xml- geronimo- corba_3.0_spec geronimo-spec-corba/pom.xml- geronimo-spec-corbaartifactId> geronimo-spec-ejb/pom.xml- geronimo-ejb_2.1_specartifactId> geronimo-spec-j2ee-connector/pom.xml- geronimo-j2ee- connector_1.5_spec geronimo-spec-j2ee-deployment/pom.xml- geronimo-j2ee- deployment_1.1_spec geronimo-spec-j2ee-jacc/pom.xml- geronimo-j2ee- jacc_1.0_spec geronimo-spec-j2ee-management/pom.xml- geronimo-j2ee- management_1.0_spec geronimo-spec-j2ee/pom.xml- geronimo-j2ee_1.4_specartifactId> geronimo-spec-javamail-1.3.1/pom.xml- geronimo- javamail_1.3.1_spec geronimo-spec-javamail-1.4/pom.xml- geronimo- javamail_1.4_spec geronimo-spec-jaxr/pom.xml- geronimo-jaxr_1.0_specartifactId> geronimo-spec-jaxrpc/pom.xml- geronimo-jaxrpc_1.1_specartifactId> geronimo-spec-jms/pom.xml- geronimo-jms_1.1_specartifactId> geronimo-spec-jsp/pom.xml- geronimo-jsp_2.0_specartifactId> geronimo-spec-jta/pom.xml- geronimo-jta_1.0.1B_specartifactId> geronimo-spec-qname/pom.xml- geronimo-qname_1.1_specartifactId> geronimo-spec-saaj/pom.xml- geronimo-saaj_1.1_specartifactId> geronimo-spec-servlet-2.4/pom.xml- geronimo- servlet_2.4_spec geronimo-spec-servlet-2.5/pom.xml- geronimo- servlet_2.5_spec -David [1] http://marc.theaimsgroup.com/?l=geronimo-dev&m=113857091823325&w=2 --jason -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: 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 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 te
Re: Organization and versioning of specs; a new proposal
On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do - for the tag names as maven does. I'm planning on putting - under / but m2 handles this, all it needs it the root to exist. There's also a small catch in that the directories we've been using are not the artifactIds. I don't understand... :-\ --jason -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: 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 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
Re: Organization and versioning of specs; a new proposal
I guess I'd still prefer we do - 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: 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 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 appropri
Re: Organization and versioning of specs; a new proposal
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: 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-ejb 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 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 give
Re: Organization and versioning of specs; a new proposal
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/
specs/tags//
And if needed:
specs/branches//
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,
wh
Re: Organization and versioning of specs; a new proposal
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.
--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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
What is the status on 1.1.1 wrt this change? Can I go ahead and make
these changes?
--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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
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/
specs/tags//
And if needed:
specs/branches//
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
element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
Jason van Zyl wrote: On 11 Aug 06, at 7:05 PM 11 Aug 06, Jason Dillon wrote: I'm going to let this sit for the weekend, and if there are no objections I'd like to implement this. Or do we need a formal vote to to this? You seem to have everyone's buy in, you've made the proposal and provided reasoning. Lazy consensus can come into play because you're doing the work so I say go for it, if someone objects it can be dealt with, but it doesn't look like anyone will. This is a change and, so, IIUC falls under the RTC process. Otherwise, go for it. Regards. Alan
Re: Organization and versioning of specs; a new proposal
This is a good idea.
Regards,
Alan
Jason Dillon wrote:
On Aug 11, 2006, at 12:32 PM, David Blevins wrote:
Have you thought about using specs/tags/- for
the tag names? That's what maven does, so I'm guessing you noticed
and didn't like it for some reason.
The issue with that is that specs/tags becomes massive over time and
not easy to grok.
But you are right, the release plugin puts the artifact on there too,
so its more like:
specs/tags//-
--jason
-David
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On 11 Aug 06, at 7:05 PM 11 Aug 06, Jason Dillon wrote:
I'm going to let this sit for the weekend, and if there are no
objections I'd like to implement this.
Or do we need a formal vote to to this?
You seem to have everyone's buy in, you've made the proposal and
provided reasoning. Lazy consensus can come into play because you're
doing the work so I say go for it, if someone objects it can be dealt
with, but it doesn't look like anyone will.
Jason.
--jason
On Aug 11, 2006, at 12:44 PM, Dain Sundstrom wrote:
This feels like an excellent compromise where we can easily build
them together and they can be independently versioned.
-dain
On Aug 11, 2006, at 12:15 PM, 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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Jason van Zyl
[EMAIL PROTECTED]
Re: Organization and versioning of specs; a new proposal
On 11 Aug 06, at 3:15 PM 11 Aug 06, 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. +1 That's what I originally put there. I didn't know it was split up into a separate module for each as I unsub'd from the list for a while. Jason van Zyl [EMAIL PROTECTED]
Re: Organization and versioning of specs; a new proposal
I'm going to let this sit for the weekend, and if there are no
objections I'd like to implement this.
Or do we need a formal vote to to this?
--jason
On Aug 11, 2006, at 12:44 PM, Dain Sundstrom wrote:
This feels like an excellent compromise where we can easily build
them together and they can be independently versioned.
-dain
On Aug 11, 2006, at 12:15 PM, 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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
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/
specs/tags//
And if needed:
specs/branches//
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
element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
On Aug 11, 2006, at 12:32 PM, David Blevins wrote:
Have you thought about using specs/tags/- for
the tag names? That's what maven does, so I'm guessing you noticed
and didn't like it for some reason.
The issue with that is that specs/tags becomes massive over time and
not easy to grok.
But you are right, the release plugin puts the artifact on there too,
so its more like:
specs/tags//-
--jason
-David
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
This feels like an excellent compromise where we can easily build
them together and they can be independently versioned.
-dain
On Aug 11, 2006, at 12:15 PM, 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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
This is a good idea. I like it.
+1
Cheers
Prasad
On 8/11/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
Sounds fine to me.
Thanks,
Aaron
On 8/11/06, Jason Dillon <[EMAIL PROTECTED]> 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/
> specs/tags//
>
> And if needed:
>
> specs/branches//
>
> 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 element of the respective pom.
>
> Comments?
>
> --jason
>
>
Re: Organization and versioning of specs; a new proposal
I like the direction. I think David's comment about
tags/artifact-version works also but tags will get a little busy. If one approach is closer to
Maven behaviour in terms of recommended practices I'd go with that .
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/
specs/tags//
And if needed:
specs/branches//
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
element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
Sounds fine to me.
Thanks,
Aaron
On 8/11/06, Jason Dillon <[EMAIL PROTECTED]> 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/
specs/tags//
And if needed:
specs/branches//
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 element of the respective pom.
Comments?
--jason
Re: Organization and versioning of specs; a new proposal
Great proposal, I like this. Comment below...
On Aug 11, 2006, at 12:15 PM, Jason Dillon wrote:
[...]
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/
specs/tags//
Have you thought about using specs/tags/- for
the tag names? That's what maven does, so I'm guessing you noticed
and didn't like it for some reason.
-David
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 element of the respective pom.
Comments?
--jason
