One version for specs

[Jason Dillon <ja...@planet57.com>]

Hi, me again... and the specs topic again too.

I have been thinking about this for quite a while and I believe that  
it would be in the best interest of the project to treat our specs as  
a project and use one version to release the spec modules under.

Doing so will greatly reduce the complexity to maintain the specs  
tree and to make new releases.  It also reduces the need for a bunch  
of config in the root pom.xml for specs... all properties can be  
removed and most of the dependencyManagement can be removed as well.

Releases can be done using the release plugin with out any twists of  
configuration, which should be straight forward.  The alternative is  
that the configuration becomes more compkicated and that in order to  
make a release users will have to have much more knowledge of how  
Maven works and how we have configured it... which I am betting will  
only lead to something being missed which will only lead to problems  
down the road.

One thing to remember for those of you who are gonna say that some  
spec module has not changed in x-years... is that the release is code  
+ pom configuration... and even if the code has not changed, the  
configuration has, and thus it warrants a new release to be made.

Specs do not get released that often anyways, so I don't really see  
any huge problem with re-releasing specs under a new version when  
something is added (or fixed).

1 version number for us (and our users) is IMO much, much simperer  
than 30+ versions.  For example, if I am a developer and want to use  
the latest versions of all of the specs that I use, I would much  
rather know that there is just one version to track, instead of  
needing to hunt down what the latest version of each spec is... after  
all I don't care what the version is... I just want the latest version.

Also remember that some spec modules depend on other spec modules, so  
ideally when a dependency module is released, the dependent modules  
should be released to pickup the latest versions.  Doing this is  
automatic with the one-version scheme, but becomes much more work  
with independent versions... which will almost certainly result in  
dependent modules not getting updated as they should.

  * * *

We have also been waiting for some resolution on this to simplify the  
main server build.  It will take all of 10 minutes for me to fix the  
specs build to use one version and make a release than can be used by  
the server build (and allow the bootstrap of specs to be removed).

So, my recommendation is to:

   1) change the specs project to use one version, 2.0-SNAPSHOT, and  
publish the snaps
   2) update the server build to use 2.0-SNAPSHOT for all specs
   3) remove the specs build from bootstrap

I believe this is the best option for the project and community at  
this point.  I would like to implement this ASAP to simplify the  
server build.  If after some time folks do not feel that is working  
well, then we can revisit and consider either splitting up into a  
multi-trunk build or using independent version numbers.  But, I do  
believe that most will find that the advantages of using one version  
far out-weight the disadvantages.

NOTE:

For those unaware, Dain did an experiment with version ranges... but  
it looks like this will not work well right now as there is not  
general support for use of ranges in most plugins that we depend on.   
Also several members of the m2 team have suggested that ranges are  
buggy.  This was my general impression that I brought up to Dain  
weeks ago when we talked about using ranges (and when he said he  
would try it out).  So, for now at least I think that ranges will not  
work for us.

--jason

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Oct 2, 2006, at 12:38 PM, Jason Dillon wrote:

> IMO there is no "best" way to handle this problem.  There is only  
> good and bad for each solution, but there is no smoking gun to  
> solve everyones issues.
>
> I already sent out that itty bitty note about the release being jar  
> + pom(s) but I wanted to clarify that even more...
>
> If you take the current specs build... all of the versions of the  
> specs are defined in the top-level pom, which means that whenever  
> any module need to change, that its parent will also need to  
> change, and that change to its parent may cause other specs to need  
> to be changed (if they depend on the spec that has been  
> versioned).  Those dependent modules really should be released in  
> the same process too, but there is no easy mechanism to automate  
> that in the multi-versioned build.  Which leaves that task up to  
> process... and as I have mentioned before, will almost certainly  
> result in problems due to lack of insight into maven and how the  
> multi-version spec build functions.
>
> If we have each spec in its own tree, that means that nothing is  
> shared and all referenced version numbers are hardcoded, which  
> means that when a dependency module is released that it is up to  
> the process again to make sure that each dependent module gets  
> updated and then released... which is even more problematic for  
> keeping things in-sync and now users need to have even more insight  
> into how the specs related to each other and will almost certainly  
> end up in disaster, especially as more specs are added and more so  
> when developers come and go.


What are the interdependencies between spec jars?  I don't think  
there are many.  GIven this fact, I'm not sure that there needs to be  
a root POM, _in specs_, that binds all the versions together.


Regards,
Alan

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

You may be right... but I still believe one version is going to be  
easier for us.  And I am willing to make the changes to get one  
version working as it is simple and easy (with a decent network  
connection it can all be done in under an hour).

Almost anything else is going to take much longer and I believe the  
comparison of the work to rectify the state of the specs build is  
indicative of the effort it is going to take to maintain more and  
more of em.

But... we need to fix this.  Right now we can not even publish new  
specs for development as half of them will end up published to the  
snapshot repo and another half to the sync repo.  This is due to the  
versions in trunk not being reset to SNAPSHOT versions after a  
release... which is also some more evidence that the multi-version  
method is problematic as non of the versions in trunk should have  
been set to a non-SNAPSHOT for more than a brief moment when a  
release was being made.

With one version and the release plugin this problem goes away, and  
any dependencies are automatically updated to the correct version...  
which means that everything will be insync... all the time... at the  
slight cost of re-publishing new artifacts for modules which have had  
no code change... a minor cost worth the price of easy maintainable  
automation.

--jason


On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:

> I hear you, but underlying your case is the assumption that a lot of
> specs depend on each other.  I'm not convinced that's true.
> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
> specs.  I guess underlying the compromise proposal is the assumtion
> that at this point J2EE 1.4 is fairly unlikely to need any changes, so
> a backward dependency from 1.5 to 1.4 is unlikely to need much
> maintainance.
>
> I'm not sure how many unaligned specs would have other spec
> dependencies, but I can't think of any.  The only dependencies I can
> really think of are mail on activation, web services on mail and
> activation, and JSP on servlet....  I'm sure there are a few more, but
> I don't think it's anything like the inter-module dependencies of,
> say, Geronimo itself.
>
> Thanks,
>     Aaron
>
> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>> IMO there is no "best" way to handle this problem.  There is only
>> good and bad for each solution, but there is no smoking gun to solve
>> everyones issues.
>>
>> I already sent out that itty bitty note about the release being jar +
>> pom(s) but I wanted to clarify that even more...
>>
>> If you take the current specs build... all of the versions of the
>> specs are defined in the top-level pom, which means that whenever any
>> module need to change, that its parent will also need to change, and
>> that change to its parent may cause other specs to need to be changed
>> (if they depend on the spec that has been versioned).  Those
>> dependent modules really should be released in the same process too,
>> but there is no easy mechanism to automate that in the multi-
>> versioned build.  Which leaves that task up to process... and as I
>> have mentioned before, will almost certainly result in problems due
>> to lack of insight into maven and how the multi-version spec build
>> functions.
>>
>> If we have each spec in its own tree, that means that nothing is
>> shared and all referenced version numbers are hardcoded, which means
>> that when a dependency module is released that it is up to the
>> process again to make sure that each dependent module gets updated
>> and then released... which is even more problematic for keeping
>> things in-sync and now users need to have even more insight into how
>> the specs related to each other and will almost certainly end up in
>> disaster, especially as more specs are added and more so when
>> developers come and go.
>>
>> Both multi-version schemes seem to end up going down the same path
>> towards a maintenance nightmare.
>>
>> But, if you compare this with the one version... if a dependency
>> module changes, then all dependent modules will automatically get
>> configured with the right version, will be included in the tag, will
>> be included in the docs (site stuff), will be published and all of
>> this can be done in a few simple steps... all of which are standard
>> m2-isms so anyone who knows m2 should be able to easily understand
>> what is going on.
>>
>> I agree with you on some levels... and in a perfect world maven would
>> be able to make this happen for us as easily as it can with a single-
>> version scheme... but right now this is not the case.  Maybe in 6mo
>> or a year maven will have a solution for us, but today it does not.
>>
>>   * * *
>>
>> It is still my recommendation that it is best for the project in the
>> short to medium term that one version be used to manage specs... and
>> to commit to revisit later when there is better support for multi-
>> versioned build automation.
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>
>> > I don't think that this is a good idea.  Versions should reflect
>> > the contents of the jar not the fact that an unrelated spec was
>> > released/patched/updated.
>> >
>> >
>> > Regards,
>> > Alan
>> >
>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>> >
>> >> Hi, me again... and the specs topic again too.
>> >>
>> >> I have been thinking about this for quite a while and I believe
>> >> that it would be in the best interest of the project to treat our
>> >> specs as a project and use one version to release the spec modules
>> >> under.
>> >>
>> >> Doing so will greatly reduce the complexity to maintain the specs
>> >> tree and to make new releases.  It also reduces the need for a
>> >> bunch of config in the root pom.xml for specs... all properties
>> >> can be removed and most of the dependencyManagement can be removed
>> >> as well.
>> >>
>> >> Releases can be done using the release plugin with out any twists
>> >> of configuration, which should be straight forward.  The
>> >> alternative is that the configuration becomes more compkicated and
>> >> that in order to make a release users will have to have much more
>> >> knowledge of how Maven works and how we have configured it...
>> >> which I am betting will only lead to something being missed which
>> >> will only lead to problems down the road.
>> >>
>> >> One thing to remember for those of you who are gonna say that some
>> >> spec module has not changed in x-years... is that the release is
>> >> code + pom configuration... and even if the code has not changed,
>> >> the configuration has, and thus it warrants a new release to be  
>> made.
>> >>
>> >> Specs do not get released that often anyways, so I don't really
>> >> see any huge problem with re-releasing specs under a new version
>> >> when something is added (or fixed).
>> >>
>> >> 1 version number for us (and our users) is IMO much, much simperer
>> >> than 30+ versions.  For example, if I am a developer and want to
>> >> use the latest versions of all of the specs that I use, I would
>> >> much rather know that there is just one version to track, instead
>> >> of needing to hunt down what the latest version of each spec is...
>> >> after all I don't care what the version is... I just want the
>> >> latest version.
>> >>
>> >> Also remember that some spec modules depend on other spec modules,
>> >> so ideally when a dependency module is released, the dependent
>> >> modules should be released to pickup the latest versions.  Doing
>> >> this is automatic with the one-version scheme, but becomes much
>> >> more work with independent versions... which will almost certainly
>> >> result in dependent modules not getting updated as they should.
>> >>
>> >>  * * *
>> >>
>> >> We have also been waiting for some resolution on this to simplify
>> >> the main server build.  It will take all of 10 minutes for me to
>> >> fix the specs build to use one version and make a release than can
>> >> be used by the server build (and allow the bootstrap of specs to
>> >> be removed).
>> >>
>> >> So, my recommendation is to:
>> >>
>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>> >> and publish the snaps
>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>> >>   3) remove the specs build from bootstrap
>> >>
>> >> I believe this is the best option for the project and community at
>> >> this point.  I would like to implement this ASAP to simplify the
>> >> server build.  If after some time folks do not feel that is
>> >> working well, then we can revisit and consider either splitting up
>> >> into a multi-trunk build or using independent version numbers.
>> >> But, I do believe that most will find that the advantages of using
>> >> one version far out-weight the disadvantages.
>> >>
>> >> NOTE:
>> >>
>> >> For those unaware, Dain did an experiment with version ranges...
>> >> but it looks like this will not work well right now as there is
>> >> not general support for use of ranges in most plugins that we
>> >> depend on.  Also several members of the m2 team have suggested
>> >> that ranges are buggy.  This was my general impression that I
>> >> brought up to Dain weeks ago when we talked about using ranges
>> >> (and when he said he would try it out).  So, for now at least I
>> >> think that ranges will not work for us.
>> >>
>> >> --jason
>> >>
>> >>
>> >
>>
>>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

For the two classes of users that I mentioned earlier, the work will  
not be significant.  I'm not certain that the post-it note spectre  
applies to this narrow domain.


Regards,
Alan


On Oct 3, 2006, at 11:14 AM, Jason Dillon wrote:

> It does not matter how often it happens.  The fact that they can be  
> changed, and most *will* have some change made to them, increases  
> the work to manage them significantly.
>
> --jason
>
>
> On Oct 3, 2006, at 11:09 AM, Alan D. Cabrera wrote:
>
>> These don't change all that often, IIRC.
>>
>>
>> Regards,
>> Alan
>>
>> On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:
>>
>>> About 1/3 of the specs depend on other specs (not including the  
>>> uber 1.4 spec):
>>>
>>> ejb 2.1 -> jta 1.0.1b
>>> ejb3 -> jta 1.1, interceptor, annotation
>>> conector 1.5 -> jta 1.0.1b
>>> jacc -> servlet 2.4
>>> j2ee mgmt -> ejb 2.1
>>> javamail 1.3.1 -> activation
>>> javamail 1.4 -> activation
>>> jaxr -> activation
>>> jaxrpc -> saaj, qname, servlet 2.4
>>> jsp -> servlet 2.4
>>> saaj -> activation
>>>
>>> --jason
>>>
>>>
>>> On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:
>>>
>>>> I hear you, but underlying your case is the assumption that a  
>>>> lot of
>>>> specs depend on each other.  I'm not convinced that's true.
>>>> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non- 
>>>> J2EE
>>>> specs.  I guess underlying the compromise proposal is the assumtion
>>>> that at this point J2EE 1.4 is fairly unlikely to need any  
>>>> changes, so
>>>> a backward dependency from 1.5 to 1.4 is unlikely to need much
>>>> maintainance.
>>>>
>>>> I'm not sure how many unaligned specs would have other spec
>>>> dependencies, but I can't think of any.  The only dependencies I  
>>>> can
>>>> really think of are mail on activation, web services on mail and
>>>> activation, and JSP on servlet....  I'm sure there are a few  
>>>> more, but
>>>> I don't think it's anything like the inter-module dependencies of,
>>>> say, Geronimo itself.
>>>>
>>>> Thanks,
>>>>     Aaron
>>>>
>>>> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>>>>> IMO there is no "best" way to handle this problem.  There is only
>>>>> good and bad for each solution, but there is no smoking gun to  
>>>>> solve
>>>>> everyones issues.
>>>>>
>>>>> I already sent out that itty bitty note about the release being  
>>>>> jar +
>>>>> pom(s) but I wanted to clarify that even more...
>>>>>
>>>>> If you take the current specs build... all of the versions of the
>>>>> specs are defined in the top-level pom, which means that  
>>>>> whenever any
>>>>> module need to change, that its parent will also need to  
>>>>> change, and
>>>>> that change to its parent may cause other specs to need to be  
>>>>> changed
>>>>> (if they depend on the spec that has been versioned).  Those
>>>>> dependent modules really should be released in the same process  
>>>>> too,
>>>>> but there is no easy mechanism to automate that in the multi-
>>>>> versioned build.  Which leaves that task up to process... and as I
>>>>> have mentioned before, will almost certainly result in problems  
>>>>> due
>>>>> to lack of insight into maven and how the multi-version spec build
>>>>> functions.
>>>>>
>>>>> If we have each spec in its own tree, that means that nothing is
>>>>> shared and all referenced version numbers are hardcoded, which  
>>>>> means
>>>>> that when a dependency module is released that it is up to the
>>>>> process again to make sure that each dependent module gets updated
>>>>> and then released... which is even more problematic for keeping
>>>>> things in-sync and now users need to have even more insight  
>>>>> into how
>>>>> the specs related to each other and will almost certainly end  
>>>>> up in
>>>>> disaster, especially as more specs are added and more so when
>>>>> developers come and go.
>>>>>
>>>>> Both multi-version schemes seem to end up going down the same path
>>>>> towards a maintenance nightmare.
>>>>>
>>>>> But, if you compare this with the one version... if a dependency
>>>>> module changes, then all dependent modules will automatically get
>>>>> configured with the right version, will be included in the tag,  
>>>>> will
>>>>> be included in the docs (site stuff), will be published and all of
>>>>> this can be done in a few simple steps... all of which are  
>>>>> standard
>>>>> m2-isms so anyone who knows m2 should be able to easily understand
>>>>> what is going on.
>>>>>
>>>>> I agree with you on some levels... and in a perfect world maven  
>>>>> would
>>>>> be able to make this happen for us as easily as it can with a  
>>>>> single-
>>>>> version scheme... but right now this is not the case.  Maybe in  
>>>>> 6mo
>>>>> or a year maven will have a solution for us, but today it does  
>>>>> not.
>>>>>
>>>>>   * * *
>>>>>
>>>>> It is still my recommendation that it is best for the project  
>>>>> in the
>>>>> short to medium term that one version be used to manage  
>>>>> specs... and
>>>>> to commit to revisit later when there is better support for multi-
>>>>> versioned build automation.
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>>>>
>>>>> > I don't think that this is a good idea.  Versions should reflect
>>>>> > the contents of the jar not the fact that an unrelated spec was
>>>>> > released/patched/updated.
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Alan
>>>>> >
>>>>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>>>>> >
>>>>> >> Hi, me again... and the specs topic again too.
>>>>> >>
>>>>> >> I have been thinking about this for quite a while and I believe
>>>>> >> that it would be in the best interest of the project to  
>>>>> treat our
>>>>> >> specs as a project and use one version to release the spec  
>>>>> modules
>>>>> >> under.
>>>>> >>
>>>>> >> Doing so will greatly reduce the complexity to maintain the  
>>>>> specs
>>>>> >> tree and to make new releases.  It also reduces the need for a
>>>>> >> bunch of config in the root pom.xml for specs... all properties
>>>>> >> can be removed and most of the dependencyManagement can be  
>>>>> removed
>>>>> >> as well.
>>>>> >>
>>>>> >> Releases can be done using the release plugin with out any  
>>>>> twists
>>>>> >> of configuration, which should be straight forward.  The
>>>>> >> alternative is that the configuration becomes more  
>>>>> compkicated and
>>>>> >> that in order to make a release users will have to have much  
>>>>> more
>>>>> >> knowledge of how Maven works and how we have configured it...
>>>>> >> which I am betting will only lead to something being missed  
>>>>> which
>>>>> >> will only lead to problems down the road.
>>>>> >>
>>>>> >> One thing to remember for those of you who are gonna say  
>>>>> that some
>>>>> >> spec module has not changed in x-years... is that the  
>>>>> release is
>>>>> >> code + pom configuration... and even if the code has not  
>>>>> changed,
>>>>> >> the configuration has, and thus it warrants a new release to  
>>>>> be made.
>>>>> >>
>>>>> >> Specs do not get released that often anyways, so I don't really
>>>>> >> see any huge problem with re-releasing specs under a new  
>>>>> version
>>>>> >> when something is added (or fixed).
>>>>> >>
>>>>> >> 1 version number for us (and our users) is IMO much, much  
>>>>> simperer
>>>>> >> than 30+ versions.  For example, if I am a developer and  
>>>>> want to
>>>>> >> use the latest versions of all of the specs that I use, I would
>>>>> >> much rather know that there is just one version to track,  
>>>>> instead
>>>>> >> of needing to hunt down what the latest version of each spec  
>>>>> is...
>>>>> >> after all I don't care what the version is... I just want the
>>>>> >> latest version.
>>>>> >>
>>>>> >> Also remember that some spec modules depend on other spec  
>>>>> modules,
>>>>> >> so ideally when a dependency module is released, the dependent
>>>>> >> modules should be released to pickup the latest versions.   
>>>>> Doing
>>>>> >> this is automatic with the one-version scheme, but becomes much
>>>>> >> more work with independent versions... which will almost  
>>>>> certainly
>>>>> >> result in dependent modules not getting updated as they should.
>>>>> >>
>>>>> >>  * * *
>>>>> >>
>>>>> >> We have also been waiting for some resolution on this to  
>>>>> simplify
>>>>> >> the main server build.  It will take all of 10 minutes for  
>>>>> me to
>>>>> >> fix the specs build to use one version and make a release  
>>>>> than can
>>>>> >> be used by the server build (and allow the bootstrap of  
>>>>> specs to
>>>>> >> be removed).
>>>>> >>
>>>>> >> So, my recommendation is to:
>>>>> >>
>>>>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>>>>> >> and publish the snaps
>>>>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>>>> >>   3) remove the specs build from bootstrap
>>>>> >>
>>>>> >> I believe this is the best option for the project and  
>>>>> community at
>>>>> >> this point.  I would like to implement this ASAP to simplify  
>>>>> the
>>>>> >> server build.  If after some time folks do not feel that is
>>>>> >> working well, then we can revisit and consider either  
>>>>> splitting up
>>>>> >> into a multi-trunk build or using independent version numbers.
>>>>> >> But, I do believe that most will find that the advantages of  
>>>>> using
>>>>> >> one version far out-weight the disadvantages.
>>>>> >>
>>>>> >> NOTE:
>>>>> >>
>>>>> >> For those unaware, Dain did an experiment with version  
>>>>> ranges...
>>>>> >> but it looks like this will not work well right now as there is
>>>>> >> not general support for use of ranges in most plugins that we
>>>>> >> depend on.  Also several members of the m2 team have suggested
>>>>> >> that ranges are buggy.  This was my general impression that I
>>>>> >> brought up to Dain weeks ago when we talked about using ranges
>>>>> >> (and when he said he would try it out).  So, for now at least I
>>>>> >> think that ranges will not work for us.
>>>>> >>
>>>>> >> --jason
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>
>>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

It does not matter how often it happens.  The fact that they can be  
changed, and most *will* have some change made to them, increases the  
work to manage them significantly.

--jason


On Oct 3, 2006, at 11:09 AM, Alan D. Cabrera wrote:

> These don't change all that often, IIRC.
>
>
> Regards,
> Alan
>
> On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:
>
>> About 1/3 of the specs depend on other specs (not including the  
>> uber 1.4 spec):
>>
>> ejb 2.1 -> jta 1.0.1b
>> ejb3 -> jta 1.1, interceptor, annotation
>> conector 1.5 -> jta 1.0.1b
>> jacc -> servlet 2.4
>> j2ee mgmt -> ejb 2.1
>> javamail 1.3.1 -> activation
>> javamail 1.4 -> activation
>> jaxr -> activation
>> jaxrpc -> saaj, qname, servlet 2.4
>> jsp -> servlet 2.4
>> saaj -> activation
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:
>>
>>> I hear you, but underlying your case is the assumption that a lot of
>>> specs depend on each other.  I'm not convinced that's true.
>>> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
>>> specs.  I guess underlying the compromise proposal is the assumtion
>>> that at this point J2EE 1.4 is fairly unlikely to need any  
>>> changes, so
>>> a backward dependency from 1.5 to 1.4 is unlikely to need much
>>> maintainance.
>>>
>>> I'm not sure how many unaligned specs would have other spec
>>> dependencies, but I can't think of any.  The only dependencies I can
>>> really think of are mail on activation, web services on mail and
>>> activation, and JSP on servlet....  I'm sure there are a few  
>>> more, but
>>> I don't think it's anything like the inter-module dependencies of,
>>> say, Geronimo itself.
>>>
>>> Thanks,
>>>     Aaron
>>>
>>> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> IMO there is no "best" way to handle this problem.  There is only
>>>> good and bad for each solution, but there is no smoking gun to  
>>>> solve
>>>> everyones issues.
>>>>
>>>> I already sent out that itty bitty note about the release being  
>>>> jar +
>>>> pom(s) but I wanted to clarify that even more...
>>>>
>>>> If you take the current specs build... all of the versions of the
>>>> specs are defined in the top-level pom, which means that  
>>>> whenever any
>>>> module need to change, that its parent will also need to change,  
>>>> and
>>>> that change to its parent may cause other specs to need to be  
>>>> changed
>>>> (if they depend on the spec that has been versioned).  Those
>>>> dependent modules really should be released in the same process  
>>>> too,
>>>> but there is no easy mechanism to automate that in the multi-
>>>> versioned build.  Which leaves that task up to process... and as I
>>>> have mentioned before, will almost certainly result in problems due
>>>> to lack of insight into maven and how the multi-version spec build
>>>> functions.
>>>>
>>>> If we have each spec in its own tree, that means that nothing is
>>>> shared and all referenced version numbers are hardcoded, which  
>>>> means
>>>> that when a dependency module is released that it is up to the
>>>> process again to make sure that each dependent module gets updated
>>>> and then released... which is even more problematic for keeping
>>>> things in-sync and now users need to have even more insight into  
>>>> how
>>>> the specs related to each other and will almost certainly end up in
>>>> disaster, especially as more specs are added and more so when
>>>> developers come and go.
>>>>
>>>> Both multi-version schemes seem to end up going down the same path
>>>> towards a maintenance nightmare.
>>>>
>>>> But, if you compare this with the one version... if a dependency
>>>> module changes, then all dependent modules will automatically get
>>>> configured with the right version, will be included in the tag,  
>>>> will
>>>> be included in the docs (site stuff), will be published and all of
>>>> this can be done in a few simple steps... all of which are standard
>>>> m2-isms so anyone who knows m2 should be able to easily understand
>>>> what is going on.
>>>>
>>>> I agree with you on some levels... and in a perfect world maven  
>>>> would
>>>> be able to make this happen for us as easily as it can with a  
>>>> single-
>>>> version scheme... but right now this is not the case.  Maybe in 6mo
>>>> or a year maven will have a solution for us, but today it does not.
>>>>
>>>>   * * *
>>>>
>>>> It is still my recommendation that it is best for the project in  
>>>> the
>>>> short to medium term that one version be used to manage specs...  
>>>> and
>>>> to commit to revisit later when there is better support for multi-
>>>> versioned build automation.
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>>>
>>>> > I don't think that this is a good idea.  Versions should reflect
>>>> > the contents of the jar not the fact that an unrelated spec was
>>>> > released/patched/updated.
>>>> >
>>>> >
>>>> > Regards,
>>>> > Alan
>>>> >
>>>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>>>> >
>>>> >> Hi, me again... and the specs topic again too.
>>>> >>
>>>> >> I have been thinking about this for quite a while and I believe
>>>> >> that it would be in the best interest of the project to treat  
>>>> our
>>>> >> specs as a project and use one version to release the spec  
>>>> modules
>>>> >> under.
>>>> >>
>>>> >> Doing so will greatly reduce the complexity to maintain the  
>>>> specs
>>>> >> tree and to make new releases.  It also reduces the need for a
>>>> >> bunch of config in the root pom.xml for specs... all properties
>>>> >> can be removed and most of the dependencyManagement can be  
>>>> removed
>>>> >> as well.
>>>> >>
>>>> >> Releases can be done using the release plugin with out any  
>>>> twists
>>>> >> of configuration, which should be straight forward.  The
>>>> >> alternative is that the configuration becomes more  
>>>> compkicated and
>>>> >> that in order to make a release users will have to have much  
>>>> more
>>>> >> knowledge of how Maven works and how we have configured it...
>>>> >> which I am betting will only lead to something being missed  
>>>> which
>>>> >> will only lead to problems down the road.
>>>> >>
>>>> >> One thing to remember for those of you who are gonna say that  
>>>> some
>>>> >> spec module has not changed in x-years... is that the release is
>>>> >> code + pom configuration... and even if the code has not  
>>>> changed,
>>>> >> the configuration has, and thus it warrants a new release to  
>>>> be made.
>>>> >>
>>>> >> Specs do not get released that often anyways, so I don't really
>>>> >> see any huge problem with re-releasing specs under a new version
>>>> >> when something is added (or fixed).
>>>> >>
>>>> >> 1 version number for us (and our users) is IMO much, much  
>>>> simperer
>>>> >> than 30+ versions.  For example, if I am a developer and want to
>>>> >> use the latest versions of all of the specs that I use, I would
>>>> >> much rather know that there is just one version to track,  
>>>> instead
>>>> >> of needing to hunt down what the latest version of each spec  
>>>> is...
>>>> >> after all I don't care what the version is... I just want the
>>>> >> latest version.
>>>> >>
>>>> >> Also remember that some spec modules depend on other spec  
>>>> modules,
>>>> >> so ideally when a dependency module is released, the dependent
>>>> >> modules should be released to pickup the latest versions.  Doing
>>>> >> this is automatic with the one-version scheme, but becomes much
>>>> >> more work with independent versions... which will almost  
>>>> certainly
>>>> >> result in dependent modules not getting updated as they should.
>>>> >>
>>>> >>  * * *
>>>> >>
>>>> >> We have also been waiting for some resolution on this to  
>>>> simplify
>>>> >> the main server build.  It will take all of 10 minutes for me to
>>>> >> fix the specs build to use one version and make a release  
>>>> than can
>>>> >> be used by the server build (and allow the bootstrap of specs to
>>>> >> be removed).
>>>> >>
>>>> >> So, my recommendation is to:
>>>> >>
>>>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>>>> >> and publish the snaps
>>>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>>> >>   3) remove the specs build from bootstrap
>>>> >>
>>>> >> I believe this is the best option for the project and  
>>>> community at
>>>> >> this point.  I would like to implement this ASAP to simplify the
>>>> >> server build.  If after some time folks do not feel that is
>>>> >> working well, then we can revisit and consider either  
>>>> splitting up
>>>> >> into a multi-trunk build or using independent version numbers.
>>>> >> But, I do believe that most will find that the advantages of  
>>>> using
>>>> >> one version far out-weight the disadvantages.
>>>> >>
>>>> >> NOTE:
>>>> >>
>>>> >> For those unaware, Dain did an experiment with version ranges...
>>>> >> but it looks like this will not work well right now as there is
>>>> >> not general support for use of ranges in most plugins that we
>>>> >> depend on.  Also several members of the m2 team have suggested
>>>> >> that ranges are buggy.  This was my general impression that I
>>>> >> brought up to Dain weeks ago when we talked about using ranges
>>>> >> (and when he said he would try it out).  So, for now at least I
>>>> >> think that ranges will not work for us.
>>>> >>
>>>> >> --jason
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>
>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

These don't change all that often, IIRC.


Regards,
Alan

On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:

> About 1/3 of the specs depend on other specs (not including the  
> uber 1.4 spec):
>
> ejb 2.1 -> jta 1.0.1b
> ejb3 -> jta 1.1, interceptor, annotation
> conector 1.5 -> jta 1.0.1b
> jacc -> servlet 2.4
> j2ee mgmt -> ejb 2.1
> javamail 1.3.1 -> activation
> javamail 1.4 -> activation
> jaxr -> activation
> jaxrpc -> saaj, qname, servlet 2.4
> jsp -> servlet 2.4
> saaj -> activation
>
> --jason
>
>
> On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:
>
>> I hear you, but underlying your case is the assumption that a lot of
>> specs depend on each other.  I'm not convinced that's true.
>> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
>> specs.  I guess underlying the compromise proposal is the assumtion
>> that at this point J2EE 1.4 is fairly unlikely to need any  
>> changes, so
>> a backward dependency from 1.5 to 1.4 is unlikely to need much
>> maintainance.
>>
>> I'm not sure how many unaligned specs would have other spec
>> dependencies, but I can't think of any.  The only dependencies I can
>> really think of are mail on activation, web services on mail and
>> activation, and JSP on servlet....  I'm sure there are a few more,  
>> but
>> I don't think it's anything like the inter-module dependencies of,
>> say, Geronimo itself.
>>
>> Thanks,
>>     Aaron
>>
>> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>>> IMO there is no "best" way to handle this problem.  There is only
>>> good and bad for each solution, but there is no smoking gun to solve
>>> everyones issues.
>>>
>>> I already sent out that itty bitty note about the release being  
>>> jar +
>>> pom(s) but I wanted to clarify that even more...
>>>
>>> If you take the current specs build... all of the versions of the
>>> specs are defined in the top-level pom, which means that whenever  
>>> any
>>> module need to change, that its parent will also need to change, and
>>> that change to its parent may cause other specs to need to be  
>>> changed
>>> (if they depend on the spec that has been versioned).  Those
>>> dependent modules really should be released in the same process too,
>>> but there is no easy mechanism to automate that in the multi-
>>> versioned build.  Which leaves that task up to process... and as I
>>> have mentioned before, will almost certainly result in problems due
>>> to lack of insight into maven and how the multi-version spec build
>>> functions.
>>>
>>> If we have each spec in its own tree, that means that nothing is
>>> shared and all referenced version numbers are hardcoded, which means
>>> that when a dependency module is released that it is up to the
>>> process again to make sure that each dependent module gets updated
>>> and then released... which is even more problematic for keeping
>>> things in-sync and now users need to have even more insight into how
>>> the specs related to each other and will almost certainly end up in
>>> disaster, especially as more specs are added and more so when
>>> developers come and go.
>>>
>>> Both multi-version schemes seem to end up going down the same path
>>> towards a maintenance nightmare.
>>>
>>> But, if you compare this with the one version... if a dependency
>>> module changes, then all dependent modules will automatically get
>>> configured with the right version, will be included in the tag, will
>>> be included in the docs (site stuff), will be published and all of
>>> this can be done in a few simple steps... all of which are standard
>>> m2-isms so anyone who knows m2 should be able to easily understand
>>> what is going on.
>>>
>>> I agree with you on some levels... and in a perfect world maven  
>>> would
>>> be able to make this happen for us as easily as it can with a  
>>> single-
>>> version scheme... but right now this is not the case.  Maybe in 6mo
>>> or a year maven will have a solution for us, but today it does not.
>>>
>>>   * * *
>>>
>>> It is still my recommendation that it is best for the project in the
>>> short to medium term that one version be used to manage specs... and
>>> to commit to revisit later when there is better support for multi-
>>> versioned build automation.
>>>
>>> --jason
>>>
>>>
>>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>>
>>> > I don't think that this is a good idea.  Versions should reflect
>>> > the contents of the jar not the fact that an unrelated spec was
>>> > released/patched/updated.
>>> >
>>> >
>>> > Regards,
>>> > Alan
>>> >
>>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>>> >
>>> >> Hi, me again... and the specs topic again too.
>>> >>
>>> >> I have been thinking about this for quite a while and I believe
>>> >> that it would be in the best interest of the project to treat our
>>> >> specs as a project and use one version to release the spec  
>>> modules
>>> >> under.
>>> >>
>>> >> Doing so will greatly reduce the complexity to maintain the specs
>>> >> tree and to make new releases.  It also reduces the need for a
>>> >> bunch of config in the root pom.xml for specs... all properties
>>> >> can be removed and most of the dependencyManagement can be  
>>> removed
>>> >> as well.
>>> >>
>>> >> Releases can be done using the release plugin with out any twists
>>> >> of configuration, which should be straight forward.  The
>>> >> alternative is that the configuration becomes more compkicated  
>>> and
>>> >> that in order to make a release users will have to have much more
>>> >> knowledge of how Maven works and how we have configured it...
>>> >> which I am betting will only lead to something being missed which
>>> >> will only lead to problems down the road.
>>> >>
>>> >> One thing to remember for those of you who are gonna say that  
>>> some
>>> >> spec module has not changed in x-years... is that the release is
>>> >> code + pom configuration... and even if the code has not changed,
>>> >> the configuration has, and thus it warrants a new release to  
>>> be made.
>>> >>
>>> >> Specs do not get released that often anyways, so I don't really
>>> >> see any huge problem with re-releasing specs under a new version
>>> >> when something is added (or fixed).
>>> >>
>>> >> 1 version number for us (and our users) is IMO much, much  
>>> simperer
>>> >> than 30+ versions.  For example, if I am a developer and want to
>>> >> use the latest versions of all of the specs that I use, I would
>>> >> much rather know that there is just one version to track, instead
>>> >> of needing to hunt down what the latest version of each spec  
>>> is...
>>> >> after all I don't care what the version is... I just want the
>>> >> latest version.
>>> >>
>>> >> Also remember that some spec modules depend on other spec  
>>> modules,
>>> >> so ideally when a dependency module is released, the dependent
>>> >> modules should be released to pickup the latest versions.  Doing
>>> >> this is automatic with the one-version scheme, but becomes much
>>> >> more work with independent versions... which will almost  
>>> certainly
>>> >> result in dependent modules not getting updated as they should.
>>> >>
>>> >>  * * *
>>> >>
>>> >> We have also been waiting for some resolution on this to simplify
>>> >> the main server build.  It will take all of 10 minutes for me to
>>> >> fix the specs build to use one version and make a release than  
>>> can
>>> >> be used by the server build (and allow the bootstrap of specs to
>>> >> be removed).
>>> >>
>>> >> So, my recommendation is to:
>>> >>
>>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>>> >> and publish the snaps
>>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>> >>   3) remove the specs build from bootstrap
>>> >>
>>> >> I believe this is the best option for the project and  
>>> community at
>>> >> this point.  I would like to implement this ASAP to simplify the
>>> >> server build.  If after some time folks do not feel that is
>>> >> working well, then we can revisit and consider either  
>>> splitting up
>>> >> into a multi-trunk build or using independent version numbers.
>>> >> But, I do believe that most will find that the advantages of  
>>> using
>>> >> one version far out-weight the disadvantages.
>>> >>
>>> >> NOTE:
>>> >>
>>> >> For those unaware, Dain did an experiment with version ranges...
>>> >> but it looks like this will not work well right now as there is
>>> >> not general support for use of ranges in most plugins that we
>>> >> depend on.  Also several members of the m2 team have suggested
>>> >> that ranges are buggy.  This was my general impression that I
>>> >> brought up to Dain weeks ago when we talked about using ranges
>>> >> (and when he said he would try it out).  So, for now at least I
>>> >> think that ranges will not work for us.
>>> >>
>>> >> --jason
>>> >>
>>> >>
>>> >
>>>
>>>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

The maintenance simplicity problem does not differentiate between  
less changing specs or not... as soon as something changes, you will  
see the increased burden of knowledge and tasks to make a complete  
release.

My point is that we do not need to spend time worry about this with  
one version.  I can easily imagine with multi-version that a release  
might be made, and then something is noticed late in the vote,  
causing several rc cycles to fix a problem because someone missed  
updating a dependent spec.  This will not happen with one version.

--jason


On Oct 3, 2006, at 9:21 AM, Dain Sundstrom wrote:

> This is good info.  Out of this list of dependencies activation is  
> the only one that changes often; the rest of the jars are just  
> interfaces (or annotations which are just interfaces).  That leaves  
> us with the following problematic specifications:
>
> javamail 1.3.1 -> activation
> javamail 1.4 -> activation
> jaxr -> activation
> jaxrpc -> saaj, qname, servlet 2.4
> saaj -> activation
>
> -dain
>
> On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:
>
>> About 1/3 of the specs depend on other specs (not including the  
>> uber 1.4 spec):
>>
>> ejb 2.1 -> jta 1.0.1b
>> ejb3 -> jta 1.1, interceptor, annotation
>> conector 1.5 -> jta 1.0.1b
>> jacc -> servlet 2.4
>> j2ee mgmt -> ejb 2.1
>> javamail 1.3.1 -> activation
>> javamail 1.4 -> activation
>> jaxr -> activation
>> jaxrpc -> saaj, qname, servlet 2.4
>> jsp -> servlet 2.4
>> saaj -> activation
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:
>>
>>> I hear you, but underlying your case is the assumption that a lot of
>>> specs depend on each other.  I'm not convinced that's true.
>>> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
>>> specs.  I guess underlying the compromise proposal is the assumtion
>>> that at this point J2EE 1.4 is fairly unlikely to need any  
>>> changes, so
>>> a backward dependency from 1.5 to 1.4 is unlikely to need much
>>> maintainance.
>>>
>>> I'm not sure how many unaligned specs would have other spec
>>> dependencies, but I can't think of any.  The only dependencies I can
>>> really think of are mail on activation, web services on mail and
>>> activation, and JSP on servlet....  I'm sure there are a few  
>>> more, but
>>> I don't think it's anything like the inter-module dependencies of,
>>> say, Geronimo itself.
>>>
>>> Thanks,
>>>     Aaron
>>>
>>> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>>>> IMO there is no "best" way to handle this problem.  There is only
>>>> good and bad for each solution, but there is no smoking gun to  
>>>> solve
>>>> everyones issues.
>>>>
>>>> I already sent out that itty bitty note about the release being  
>>>> jar +
>>>> pom(s) but I wanted to clarify that even more...
>>>>
>>>> If you take the current specs build... all of the versions of the
>>>> specs are defined in the top-level pom, which means that  
>>>> whenever any
>>>> module need to change, that its parent will also need to change,  
>>>> and
>>>> that change to its parent may cause other specs to need to be  
>>>> changed
>>>> (if they depend on the spec that has been versioned).  Those
>>>> dependent modules really should be released in the same process  
>>>> too,
>>>> but there is no easy mechanism to automate that in the multi-
>>>> versioned build.  Which leaves that task up to process... and as I
>>>> have mentioned before, will almost certainly result in problems due
>>>> to lack of insight into maven and how the multi-version spec build
>>>> functions.
>>>>
>>>> If we have each spec in its own tree, that means that nothing is
>>>> shared and all referenced version numbers are hardcoded, which  
>>>> means
>>>> that when a dependency module is released that it is up to the
>>>> process again to make sure that each dependent module gets updated
>>>> and then released... which is even more problematic for keeping
>>>> things in-sync and now users need to have even more insight into  
>>>> how
>>>> the specs related to each other and will almost certainly end up in
>>>> disaster, especially as more specs are added and more so when
>>>> developers come and go.
>>>>
>>>> Both multi-version schemes seem to end up going down the same path
>>>> towards a maintenance nightmare.
>>>>
>>>> But, if you compare this with the one version... if a dependency
>>>> module changes, then all dependent modules will automatically get
>>>> configured with the right version, will be included in the tag,  
>>>> will
>>>> be included in the docs (site stuff), will be published and all of
>>>> this can be done in a few simple steps... all of which are standard
>>>> m2-isms so anyone who knows m2 should be able to easily understand
>>>> what is going on.
>>>>
>>>> I agree with you on some levels... and in a perfect world maven  
>>>> would
>>>> be able to make this happen for us as easily as it can with a  
>>>> single-
>>>> version scheme... but right now this is not the case.  Maybe in 6mo
>>>> or a year maven will have a solution for us, but today it does not.
>>>>
>>>>   * * *
>>>>
>>>> It is still my recommendation that it is best for the project in  
>>>> the
>>>> short to medium term that one version be used to manage specs...  
>>>> and
>>>> to commit to revisit later when there is better support for multi-
>>>> versioned build automation.
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>>>
>>>> > I don't think that this is a good idea.  Versions should reflect
>>>> > the contents of the jar not the fact that an unrelated spec was
>>>> > released/patched/updated.
>>>> >
>>>> >
>>>> > Regards,
>>>> > Alan
>>>> >
>>>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>>>> >
>>>> >> Hi, me again... and the specs topic again too.
>>>> >>
>>>> >> I have been thinking about this for quite a while and I believe
>>>> >> that it would be in the best interest of the project to treat  
>>>> our
>>>> >> specs as a project and use one version to release the spec  
>>>> modules
>>>> >> under.
>>>> >>
>>>> >> Doing so will greatly reduce the complexity to maintain the  
>>>> specs
>>>> >> tree and to make new releases.  It also reduces the need for a
>>>> >> bunch of config in the root pom.xml for specs... all properties
>>>> >> can be removed and most of the dependencyManagement can be  
>>>> removed
>>>> >> as well.
>>>> >>
>>>> >> Releases can be done using the release plugin with out any  
>>>> twists
>>>> >> of configuration, which should be straight forward.  The
>>>> >> alternative is that the configuration becomes more  
>>>> compkicated and
>>>> >> that in order to make a release users will have to have much  
>>>> more
>>>> >> knowledge of how Maven works and how we have configured it...
>>>> >> which I am betting will only lead to something being missed  
>>>> which
>>>> >> will only lead to problems down the road.
>>>> >>
>>>> >> One thing to remember for those of you who are gonna say that  
>>>> some
>>>> >> spec module has not changed in x-years... is that the release is
>>>> >> code + pom configuration... and even if the code has not  
>>>> changed,
>>>> >> the configuration has, and thus it warrants a new release to  
>>>> be made.
>>>> >>
>>>> >> Specs do not get released that often anyways, so I don't really
>>>> >> see any huge problem with re-releasing specs under a new version
>>>> >> when something is added (or fixed).
>>>> >>
>>>> >> 1 version number for us (and our users) is IMO much, much  
>>>> simperer
>>>> >> than 30+ versions.  For example, if I am a developer and want to
>>>> >> use the latest versions of all of the specs that I use, I would
>>>> >> much rather know that there is just one version to track,  
>>>> instead
>>>> >> of needing to hunt down what the latest version of each spec  
>>>> is...
>>>> >> after all I don't care what the version is... I just want the
>>>> >> latest version.
>>>> >>
>>>> >> Also remember that some spec modules depend on other spec  
>>>> modules,
>>>> >> so ideally when a dependency module is released, the dependent
>>>> >> modules should be released to pickup the latest versions.  Doing
>>>> >> this is automatic with the one-version scheme, but becomes much
>>>> >> more work with independent versions... which will almost  
>>>> certainly
>>>> >> result in dependent modules not getting updated as they should.
>>>> >>
>>>> >>  * * *
>>>> >>
>>>> >> We have also been waiting for some resolution on this to  
>>>> simplify
>>>> >> the main server build.  It will take all of 10 minutes for me to
>>>> >> fix the specs build to use one version and make a release  
>>>> than can
>>>> >> be used by the server build (and allow the bootstrap of specs to
>>>> >> be removed).
>>>> >>
>>>> >> So, my recommendation is to:
>>>> >>
>>>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>>>> >> and publish the snaps
>>>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>>> >>   3) remove the specs build from bootstrap
>>>> >>
>>>> >> I believe this is the best option for the project and  
>>>> community at
>>>> >> this point.  I would like to implement this ASAP to simplify the
>>>> >> server build.  If after some time folks do not feel that is
>>>> >> working well, then we can revisit and consider either  
>>>> splitting up
>>>> >> into a multi-trunk build or using independent version numbers.
>>>> >> But, I do believe that most will find that the advantages of  
>>>> using
>>>> >> one version far out-weight the disadvantages.
>>>> >>
>>>> >> NOTE:
>>>> >>
>>>> >> For those unaware, Dain did an experiment with version ranges...
>>>> >> but it looks like this will not work well right now as there is
>>>> >> not general support for use of ranges in most plugins that we
>>>> >> depend on.  Also several members of the m2 team have suggested
>>>> >> that ranges are buggy.  This was my general impression that I
>>>> >> brought up to Dain weeks ago when we talked about using ranges
>>>> >> (and when he said he would try it out).  So, for now at least I
>>>> >> think that ranges will not work for us.
>>>> >>
>>>> >> --jason
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>

Re: One version for specs

[Dain Sundstrom <da...@iq80.com>]

This is good info.  Out of this list of dependencies activation is  
the only one that changes often; the rest of the jars are just  
interfaces (or annotations which are just interfaces).  That leaves  
us with the following problematic specifications:

javamail 1.3.1 -> activation
javamail 1.4 -> activation
jaxr -> activation
jaxrpc -> saaj, qname, servlet 2.4
saaj -> activation

-dain

On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:

> About 1/3 of the specs depend on other specs (not including the  
> uber 1.4 spec):
>
> ejb 2.1 -> jta 1.0.1b
> ejb3 -> jta 1.1, interceptor, annotation
> conector 1.5 -> jta 1.0.1b
> jacc -> servlet 2.4
> j2ee mgmt -> ejb 2.1
> javamail 1.3.1 -> activation
> javamail 1.4 -> activation
> jaxr -> activation
> jaxrpc -> saaj, qname, servlet 2.4
> jsp -> servlet 2.4
> saaj -> activation
>
> --jason
>
>
> On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:
>
>> I hear you, but underlying your case is the assumption that a lot of
>> specs depend on each other.  I'm not convinced that's true.
>> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
>> specs.  I guess underlying the compromise proposal is the assumtion
>> that at this point J2EE 1.4 is fairly unlikely to need any  
>> changes, so
>> a backward dependency from 1.5 to 1.4 is unlikely to need much
>> maintainance.
>>
>> I'm not sure how many unaligned specs would have other spec
>> dependencies, but I can't think of any.  The only dependencies I can
>> really think of are mail on activation, web services on mail and
>> activation, and JSP on servlet....  I'm sure there are a few more,  
>> but
>> I don't think it's anything like the inter-module dependencies of,
>> say, Geronimo itself.
>>
>> Thanks,
>>     Aaron
>>
>> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>>> IMO there is no "best" way to handle this problem.  There is only
>>> good and bad for each solution, but there is no smoking gun to solve
>>> everyones issues.
>>>
>>> I already sent out that itty bitty note about the release being  
>>> jar +
>>> pom(s) but I wanted to clarify that even more...
>>>
>>> If you take the current specs build... all of the versions of the
>>> specs are defined in the top-level pom, which means that whenever  
>>> any
>>> module need to change, that its parent will also need to change, and
>>> that change to its parent may cause other specs to need to be  
>>> changed
>>> (if they depend on the spec that has been versioned).  Those
>>> dependent modules really should be released in the same process too,
>>> but there is no easy mechanism to automate that in the multi-
>>> versioned build.  Which leaves that task up to process... and as I
>>> have mentioned before, will almost certainly result in problems due
>>> to lack of insight into maven and how the multi-version spec build
>>> functions.
>>>
>>> If we have each spec in its own tree, that means that nothing is
>>> shared and all referenced version numbers are hardcoded, which means
>>> that when a dependency module is released that it is up to the
>>> process again to make sure that each dependent module gets updated
>>> and then released... which is even more problematic for keeping
>>> things in-sync and now users need to have even more insight into how
>>> the specs related to each other and will almost certainly end up in
>>> disaster, especially as more specs are added and more so when
>>> developers come and go.
>>>
>>> Both multi-version schemes seem to end up going down the same path
>>> towards a maintenance nightmare.
>>>
>>> But, if you compare this with the one version... if a dependency
>>> module changes, then all dependent modules will automatically get
>>> configured with the right version, will be included in the tag, will
>>> be included in the docs (site stuff), will be published and all of
>>> this can be done in a few simple steps... all of which are standard
>>> m2-isms so anyone who knows m2 should be able to easily understand
>>> what is going on.
>>>
>>> I agree with you on some levels... and in a perfect world maven  
>>> would
>>> be able to make this happen for us as easily as it can with a  
>>> single-
>>> version scheme... but right now this is not the case.  Maybe in 6mo
>>> or a year maven will have a solution for us, but today it does not.
>>>
>>>   * * *
>>>
>>> It is still my recommendation that it is best for the project in the
>>> short to medium term that one version be used to manage specs... and
>>> to commit to revisit later when there is better support for multi-
>>> versioned build automation.
>>>
>>> --jason
>>>
>>>
>>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>>
>>> > I don't think that this is a good idea.  Versions should reflect
>>> > the contents of the jar not the fact that an unrelated spec was
>>> > released/patched/updated.
>>> >
>>> >
>>> > Regards,
>>> > Alan
>>> >
>>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>>> >
>>> >> Hi, me again... and the specs topic again too.
>>> >>
>>> >> I have been thinking about this for quite a while and I believe
>>> >> that it would be in the best interest of the project to treat our
>>> >> specs as a project and use one version to release the spec  
>>> modules
>>> >> under.
>>> >>
>>> >> Doing so will greatly reduce the complexity to maintain the specs
>>> >> tree and to make new releases.  It also reduces the need for a
>>> >> bunch of config in the root pom.xml for specs... all properties
>>> >> can be removed and most of the dependencyManagement can be  
>>> removed
>>> >> as well.
>>> >>
>>> >> Releases can be done using the release plugin with out any twists
>>> >> of configuration, which should be straight forward.  The
>>> >> alternative is that the configuration becomes more compkicated  
>>> and
>>> >> that in order to make a release users will have to have much more
>>> >> knowledge of how Maven works and how we have configured it...
>>> >> which I am betting will only lead to something being missed which
>>> >> will only lead to problems down the road.
>>> >>
>>> >> One thing to remember for those of you who are gonna say that  
>>> some
>>> >> spec module has not changed in x-years... is that the release is
>>> >> code + pom configuration... and even if the code has not changed,
>>> >> the configuration has, and thus it warrants a new release to  
>>> be made.
>>> >>
>>> >> Specs do not get released that often anyways, so I don't really
>>> >> see any huge problem with re-releasing specs under a new version
>>> >> when something is added (or fixed).
>>> >>
>>> >> 1 version number for us (and our users) is IMO much, much  
>>> simperer
>>> >> than 30+ versions.  For example, if I am a developer and want to
>>> >> use the latest versions of all of the specs that I use, I would
>>> >> much rather know that there is just one version to track, instead
>>> >> of needing to hunt down what the latest version of each spec  
>>> is...
>>> >> after all I don't care what the version is... I just want the
>>> >> latest version.
>>> >>
>>> >> Also remember that some spec modules depend on other spec  
>>> modules,
>>> >> so ideally when a dependency module is released, the dependent
>>> >> modules should be released to pickup the latest versions.  Doing
>>> >> this is automatic with the one-version scheme, but becomes much
>>> >> more work with independent versions... which will almost  
>>> certainly
>>> >> result in dependent modules not getting updated as they should.
>>> >>
>>> >>  * * *
>>> >>
>>> >> We have also been waiting for some resolution on this to simplify
>>> >> the main server build.  It will take all of 10 minutes for me to
>>> >> fix the specs build to use one version and make a release than  
>>> can
>>> >> be used by the server build (and allow the bootstrap of specs to
>>> >> be removed).
>>> >>
>>> >> So, my recommendation is to:
>>> >>
>>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>>> >> and publish the snaps
>>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>> >>   3) remove the specs build from bootstrap
>>> >>
>>> >> I believe this is the best option for the project and  
>>> community at
>>> >> this point.  I would like to implement this ASAP to simplify the
>>> >> server build.  If after some time folks do not feel that is
>>> >> working well, then we can revisit and consider either  
>>> splitting up
>>> >> into a multi-trunk build or using independent version numbers.
>>> >> But, I do believe that most will find that the advantages of  
>>> using
>>> >> one version far out-weight the disadvantages.
>>> >>
>>> >> NOTE:
>>> >>
>>> >> For those unaware, Dain did an experiment with version ranges...
>>> >> but it looks like this will not work well right now as there is
>>> >> not general support for use of ranges in most plugins that we
>>> >> depend on.  Also several members of the m2 team have suggested
>>> >> that ranges are buggy.  This was my general impression that I
>>> >> brought up to Dain weeks ago when we talked about using ranges
>>> >> (and when he said he would try it out).  So, for now at least I
>>> >> think that ranges will not work for us.
>>> >>
>>> >> --jason
>>> >>
>>> >>
>>> >
>>>
>>>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

About 1/3 of the specs depend on other specs (not including the uber  
1.4 spec):

ejb 2.1 -> jta 1.0.1b
ejb3 -> jta 1.1, interceptor, annotation
conector 1.5 -> jta 1.0.1b
jacc -> servlet 2.4
j2ee mgmt -> ejb 2.1
javamail 1.3.1 -> activation
javamail 1.4 -> activation
jaxr -> activation
jaxrpc -> saaj, qname, servlet 2.4
jsp -> servlet 2.4
saaj -> activation

--jason


On Oct 2, 2006, at 1:38 PM, Aaron Mulder wrote:

> I hear you, but underlying your case is the assumption that a lot of
> specs depend on each other.  I'm not convinced that's true.
> Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
> specs.  I guess underlying the compromise proposal is the assumtion
> that at this point J2EE 1.4 is fairly unlikely to need any changes, so
> a backward dependency from 1.5 to 1.4 is unlikely to need much
> maintainance.
>
> I'm not sure how many unaligned specs would have other spec
> dependencies, but I can't think of any.  The only dependencies I can
> really think of are mail on activation, web services on mail and
> activation, and JSP on servlet....  I'm sure there are a few more, but
> I don't think it's anything like the inter-module dependencies of,
> say, Geronimo itself.
>
> Thanks,
>     Aaron
>
> On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
>> IMO there is no "best" way to handle this problem.  There is only
>> good and bad for each solution, but there is no smoking gun to solve
>> everyones issues.
>>
>> I already sent out that itty bitty note about the release being jar +
>> pom(s) but I wanted to clarify that even more...
>>
>> If you take the current specs build... all of the versions of the
>> specs are defined in the top-level pom, which means that whenever any
>> module need to change, that its parent will also need to change, and
>> that change to its parent may cause other specs to need to be changed
>> (if they depend on the spec that has been versioned).  Those
>> dependent modules really should be released in the same process too,
>> but there is no easy mechanism to automate that in the multi-
>> versioned build.  Which leaves that task up to process... and as I
>> have mentioned before, will almost certainly result in problems due
>> to lack of insight into maven and how the multi-version spec build
>> functions.
>>
>> If we have each spec in its own tree, that means that nothing is
>> shared and all referenced version numbers are hardcoded, which means
>> that when a dependency module is released that it is up to the
>> process again to make sure that each dependent module gets updated
>> and then released... which is even more problematic for keeping
>> things in-sync and now users need to have even more insight into how
>> the specs related to each other and will almost certainly end up in
>> disaster, especially as more specs are added and more so when
>> developers come and go.
>>
>> Both multi-version schemes seem to end up going down the same path
>> towards a maintenance nightmare.
>>
>> But, if you compare this with the one version... if a dependency
>> module changes, then all dependent modules will automatically get
>> configured with the right version, will be included in the tag, will
>> be included in the docs (site stuff), will be published and all of
>> this can be done in a few simple steps... all of which are standard
>> m2-isms so anyone who knows m2 should be able to easily understand
>> what is going on.
>>
>> I agree with you on some levels... and in a perfect world maven would
>> be able to make this happen for us as easily as it can with a single-
>> version scheme... but right now this is not the case.  Maybe in 6mo
>> or a year maven will have a solution for us, but today it does not.
>>
>>   * * *
>>
>> It is still my recommendation that it is best for the project in the
>> short to medium term that one version be used to manage specs... and
>> to commit to revisit later when there is better support for multi-
>> versioned build automation.
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>>
>> > I don't think that this is a good idea.  Versions should reflect
>> > the contents of the jar not the fact that an unrelated spec was
>> > released/patched/updated.
>> >
>> >
>> > Regards,
>> > Alan
>> >
>> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>> >
>> >> Hi, me again... and the specs topic again too.
>> >>
>> >> I have been thinking about this for quite a while and I believe
>> >> that it would be in the best interest of the project to treat our
>> >> specs as a project and use one version to release the spec modules
>> >> under.
>> >>
>> >> Doing so will greatly reduce the complexity to maintain the specs
>> >> tree and to make new releases.  It also reduces the need for a
>> >> bunch of config in the root pom.xml for specs... all properties
>> >> can be removed and most of the dependencyManagement can be removed
>> >> as well.
>> >>
>> >> Releases can be done using the release plugin with out any twists
>> >> of configuration, which should be straight forward.  The
>> >> alternative is that the configuration becomes more compkicated and
>> >> that in order to make a release users will have to have much more
>> >> knowledge of how Maven works and how we have configured it...
>> >> which I am betting will only lead to something being missed which
>> >> will only lead to problems down the road.
>> >>
>> >> One thing to remember for those of you who are gonna say that some
>> >> spec module has not changed in x-years... is that the release is
>> >> code + pom configuration... and even if the code has not changed,
>> >> the configuration has, and thus it warrants a new release to be  
>> made.
>> >>
>> >> Specs do not get released that often anyways, so I don't really
>> >> see any huge problem with re-releasing specs under a new version
>> >> when something is added (or fixed).
>> >>
>> >> 1 version number for us (and our users) is IMO much, much simperer
>> >> than 30+ versions.  For example, if I am a developer and want to
>> >> use the latest versions of all of the specs that I use, I would
>> >> much rather know that there is just one version to track, instead
>> >> of needing to hunt down what the latest version of each spec is...
>> >> after all I don't care what the version is... I just want the
>> >> latest version.
>> >>
>> >> Also remember that some spec modules depend on other spec modules,
>> >> so ideally when a dependency module is released, the dependent
>> >> modules should be released to pickup the latest versions.  Doing
>> >> this is automatic with the one-version scheme, but becomes much
>> >> more work with independent versions... which will almost certainly
>> >> result in dependent modules not getting updated as they should.
>> >>
>> >>  * * *
>> >>
>> >> We have also been waiting for some resolution on this to simplify
>> >> the main server build.  It will take all of 10 minutes for me to
>> >> fix the specs build to use one version and make a release than can
>> >> be used by the server build (and allow the bootstrap of specs to
>> >> be removed).
>> >>
>> >> So, my recommendation is to:
>> >>
>> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
>> >> and publish the snaps
>> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
>> >>   3) remove the specs build from bootstrap
>> >>
>> >> I believe this is the best option for the project and community at
>> >> this point.  I would like to implement this ASAP to simplify the
>> >> server build.  If after some time folks do not feel that is
>> >> working well, then we can revisit and consider either splitting up
>> >> into a multi-trunk build or using independent version numbers.
>> >> But, I do believe that most will find that the advantages of using
>> >> one version far out-weight the disadvantages.
>> >>
>> >> NOTE:
>> >>
>> >> For those unaware, Dain did an experiment with version ranges...
>> >> but it looks like this will not work well right now as there is
>> >> not general support for use of ranges in most plugins that we
>> >> depend on.  Also several members of the m2 team have suggested
>> >> that ranges are buggy.  This was my general impression that I
>> >> brought up to Dain weeks ago when we talked about using ranges
>> >> (and when he said he would try it out).  So, for now at least I
>> >> think that ranges will not work for us.
>> >>
>> >> --jason
>> >>
>> >>
>> >
>>
>>

Re: One version for specs

[Aaron Mulder <am...@alumni.princeton.edu>]

I hear you, but underlying your case is the assumption that a lot of
specs depend on each other.  I'm not convinced that's true.
Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
specs.  I guess underlying the compromise proposal is the assumtion
that at this point J2EE 1.4 is fairly unlikely to need any changes, so
a backward dependency from 1.5 to 1.4 is unlikely to need much
maintainance.

I'm not sure how many unaligned specs would have other spec
dependencies, but I can't think of any.  The only dependencies I can
really think of are mail on activation, web services on mail and
activation, and JSP on servlet....  I'm sure there are a few more, but
I don't think it's anything like the inter-module dependencies of,
say, Geronimo itself.

Thanks,
     Aaron

On 10/2/06, Jason Dillon <ja...@planet57.com> wrote:
> IMO there is no "best" way to handle this problem.  There is only
> good and bad for each solution, but there is no smoking gun to solve
> everyones issues.
>
> I already sent out that itty bitty note about the release being jar +
> pom(s) but I wanted to clarify that even more...
>
> If you take the current specs build... all of the versions of the
> specs are defined in the top-level pom, which means that whenever any
> module need to change, that its parent will also need to change, and
> that change to its parent may cause other specs to need to be changed
> (if they depend on the spec that has been versioned).  Those
> dependent modules really should be released in the same process too,
> but there is no easy mechanism to automate that in the multi-
> versioned build.  Which leaves that task up to process... and as I
> have mentioned before, will almost certainly result in problems due
> to lack of insight into maven and how the multi-version spec build
> functions.
>
> If we have each spec in its own tree, that means that nothing is
> shared and all referenced version numbers are hardcoded, which means
> that when a dependency module is released that it is up to the
> process again to make sure that each dependent module gets updated
> and then released... which is even more problematic for keeping
> things in-sync and now users need to have even more insight into how
> the specs related to each other and will almost certainly end up in
> disaster, especially as more specs are added and more so when
> developers come and go.
>
> Both multi-version schemes seem to end up going down the same path
> towards a maintenance nightmare.
>
> But, if you compare this with the one version... if a dependency
> module changes, then all dependent modules will automatically get
> configured with the right version, will be included in the tag, will
> be included in the docs (site stuff), will be published and all of
> this can be done in a few simple steps... all of which are standard
> m2-isms so anyone who knows m2 should be able to easily understand
> what is going on.
>
> I agree with you on some levels... and in a perfect world maven would
> be able to make this happen for us as easily as it can with a single-
> version scheme... but right now this is not the case.  Maybe in 6mo
> or a year maven will have a solution for us, but today it does not.
>
>   * * *
>
> It is still my recommendation that it is best for the project in the
> short to medium term that one version be used to manage specs... and
> to commit to revisit later when there is better support for multi-
> versioned build automation.
>
> --jason
>
>
> On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:
>
> > I don't think that this is a good idea.  Versions should reflect
> > the contents of the jar not the fact that an unrelated spec was
> > released/patched/updated.
> >
> >
> > Regards,
> > Alan
> >
> > On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
> >
> >> Hi, me again... and the specs topic again too.
> >>
> >> I have been thinking about this for quite a while and I believe
> >> that it would be in the best interest of the project to treat our
> >> specs as a project and use one version to release the spec modules
> >> under.
> >>
> >> Doing so will greatly reduce the complexity to maintain the specs
> >> tree and to make new releases.  It also reduces the need for a
> >> bunch of config in the root pom.xml for specs... all properties
> >> can be removed and most of the dependencyManagement can be removed
> >> as well.
> >>
> >> Releases can be done using the release plugin with out any twists
> >> of configuration, which should be straight forward.  The
> >> alternative is that the configuration becomes more compkicated and
> >> that in order to make a release users will have to have much more
> >> knowledge of how Maven works and how we have configured it...
> >> which I am betting will only lead to something being missed which
> >> will only lead to problems down the road.
> >>
> >> One thing to remember for those of you who are gonna say that some
> >> spec module has not changed in x-years... is that the release is
> >> code + pom configuration... and even if the code has not changed,
> >> the configuration has, and thus it warrants a new release to be made.
> >>
> >> Specs do not get released that often anyways, so I don't really
> >> see any huge problem with re-releasing specs under a new version
> >> when something is added (or fixed).
> >>
> >> 1 version number for us (and our users) is IMO much, much simperer
> >> than 30+ versions.  For example, if I am a developer and want to
> >> use the latest versions of all of the specs that I use, I would
> >> much rather know that there is just one version to track, instead
> >> of needing to hunt down what the latest version of each spec is...
> >> after all I don't care what the version is... I just want the
> >> latest version.
> >>
> >> Also remember that some spec modules depend on other spec modules,
> >> so ideally when a dependency module is released, the dependent
> >> modules should be released to pickup the latest versions.  Doing
> >> this is automatic with the one-version scheme, but becomes much
> >> more work with independent versions... which will almost certainly
> >> result in dependent modules not getting updated as they should.
> >>
> >>  * * *
> >>
> >> We have also been waiting for some resolution on this to simplify
> >> the main server build.  It will take all of 10 minutes for me to
> >> fix the specs build to use one version and make a release than can
> >> be used by the server build (and allow the bootstrap of specs to
> >> be removed).
> >>
> >> So, my recommendation is to:
> >>
> >>   1) change the specs project to use one version, 2.0-SNAPSHOT,
> >> and publish the snaps
> >>   2) update the server build to use 2.0-SNAPSHOT for all specs
> >>   3) remove the specs build from bootstrap
> >>
> >> I believe this is the best option for the project and community at
> >> this point.  I would like to implement this ASAP to simplify the
> >> server build.  If after some time folks do not feel that is
> >> working well, then we can revisit and consider either splitting up
> >> into a multi-trunk build or using independent version numbers.
> >> But, I do believe that most will find that the advantages of using
> >> one version far out-weight the disadvantages.
> >>
> >> NOTE:
> >>
> >> For those unaware, Dain did an experiment with version ranges...
> >> but it looks like this will not work well right now as there is
> >> not general support for use of ranges in most plugins that we
> >> depend on.  Also several members of the m2 team have suggested
> >> that ranges are buggy.  This was my general impression that I
> >> brought up to Dain weeks ago when we talked about using ranges
> >> (and when he said he would try it out).  So, for now at least I
> >> think that ranges will not work for us.
> >>
> >> --jason
> >>
> >>
> >
>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

IMO there is no "best" way to handle this problem.  There is only  
good and bad for each solution, but there is no smoking gun to solve  
everyones issues.

I already sent out that itty bitty note about the release being jar +  
pom(s) but I wanted to clarify that even more...

If you take the current specs build... all of the versions of the  
specs are defined in the top-level pom, which means that whenever any  
module need to change, that its parent will also need to change, and  
that change to its parent may cause other specs to need to be changed  
(if they depend on the spec that has been versioned).  Those  
dependent modules really should be released in the same process too,  
but there is no easy mechanism to automate that in the multi- 
versioned build.  Which leaves that task up to process... and as I  
have mentioned before, will almost certainly result in problems due  
to lack of insight into maven and how the multi-version spec build  
functions.

If we have each spec in its own tree, that means that nothing is  
shared and all referenced version numbers are hardcoded, which means  
that when a dependency module is released that it is up to the  
process again to make sure that each dependent module gets updated  
and then released... which is even more problematic for keeping  
things in-sync and now users need to have even more insight into how  
the specs related to each other and will almost certainly end up in  
disaster, especially as more specs are added and more so when  
developers come and go.

Both multi-version schemes seem to end up going down the same path  
towards a maintenance nightmare.

But, if you compare this with the one version... if a dependency  
module changes, then all dependent modules will automatically get  
configured with the right version, will be included in the tag, will  
be included in the docs (site stuff), will be published and all of  
this can be done in a few simple steps... all of which are standard  
m2-isms so anyone who knows m2 should be able to easily understand  
what is going on.

I agree with you on some levels... and in a perfect world maven would  
be able to make this happen for us as easily as it can with a single- 
version scheme... but right now this is not the case.  Maybe in 6mo  
or a year maven will have a solution for us, but today it does not.

  * * *

It is still my recommendation that it is best for the project in the  
short to medium term that one version be used to manage specs... and  
to commit to revisit later when there is better support for multi- 
versioned build automation.

--jason


On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:

> I don't think that this is a good idea.  Versions should reflect  
> the contents of the jar not the fact that an unrelated spec was  
> released/patched/updated.
>
>
> Regards,
> Alan
>
> On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>
>> Hi, me again... and the specs topic again too.
>>
>> I have been thinking about this for quite a while and I believe  
>> that it would be in the best interest of the project to treat our  
>> specs as a project and use one version to release the spec modules  
>> under.
>>
>> Doing so will greatly reduce the complexity to maintain the specs  
>> tree and to make new releases.  It also reduces the need for a  
>> bunch of config in the root pom.xml for specs... all properties  
>> can be removed and most of the dependencyManagement can be removed  
>> as well.
>>
>> Releases can be done using the release plugin with out any twists  
>> of configuration, which should be straight forward.  The  
>> alternative is that the configuration becomes more compkicated and  
>> that in order to make a release users will have to have much more  
>> knowledge of how Maven works and how we have configured it...  
>> which I am betting will only lead to something being missed which  
>> will only lead to problems down the road.
>>
>> One thing to remember for those of you who are gonna say that some  
>> spec module has not changed in x-years... is that the release is  
>> code + pom configuration... and even if the code has not changed,  
>> the configuration has, and thus it warrants a new release to be made.
>>
>> Specs do not get released that often anyways, so I don't really  
>> see any huge problem with re-releasing specs under a new version  
>> when something is added (or fixed).
>>
>> 1 version number for us (and our users) is IMO much, much simperer  
>> than 30+ versions.  For example, if I am a developer and want to  
>> use the latest versions of all of the specs that I use, I would  
>> much rather know that there is just one version to track, instead  
>> of needing to hunt down what the latest version of each spec is...  
>> after all I don't care what the version is... I just want the  
>> latest version.
>>
>> Also remember that some spec modules depend on other spec modules,  
>> so ideally when a dependency module is released, the dependent  
>> modules should be released to pickup the latest versions.  Doing  
>> this is automatic with the one-version scheme, but becomes much  
>> more work with independent versions... which will almost certainly  
>> result in dependent modules not getting updated as they should.
>>
>>  * * *
>>
>> We have also been waiting for some resolution on this to simplify  
>> the main server build.  It will take all of 10 minutes for me to  
>> fix the specs build to use one version and make a release than can  
>> be used by the server build (and allow the bootstrap of specs to  
>> be removed).
>>
>> So, my recommendation is to:
>>
>>   1) change the specs project to use one version, 2.0-SNAPSHOT,  
>> and publish the snaps
>>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>   3) remove the specs build from bootstrap
>>
>> I believe this is the best option for the project and community at  
>> this point.  I would like to implement this ASAP to simplify the  
>> server build.  If after some time folks do not feel that is  
>> working well, then we can revisit and consider either splitting up  
>> into a multi-trunk build or using independent version numbers.   
>> But, I do believe that most will find that the advantages of using  
>> one version far out-weight the disadvantages.
>>
>> NOTE:
>>
>> For those unaware, Dain did an experiment with version ranges...  
>> but it looks like this will not work well right now as there is  
>> not general support for use of ranges in most plugins that we  
>> depend on.  Also several members of the m2 team have suggested  
>> that ranges are buggy.  This was my general impression that I  
>> brought up to Dain weeks ago when we talked about using ranges  
>> (and when he said he would try it out).  So, for now at least I  
>> think that ranges will not work for us.
>>
>> --jason
>>
>>
>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

I take it that you are arguing that since the POM changes then the  
release jar has actually changed.  This argument already assumes that  
you're using a single version for specs.  Do I understand correctly?


Regards,
Alan

On Oct 2, 2006, at 11:11 AM, jason.dillon@gmail.com wrote:

> Remeber now.... A release is jar + pom configuration.
>
> --jason
>
>
>
>
> -----Original Message-----
> From: "Alan D. Cabrera" <li...@toolazydogs.com>
> Date: Mon, 2 Oct 2006 06:51:20
> To:dev@geronimo.apache.org
> Subject: Re: One version for specs
>
> I don't think that this is a good idea.  Versions should reflect the
> contents of the jar not the fact that an unrelated spec was released/
> patched/updated.
>
>
> Regards,
> Alan
>
> On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
>
>> Hi, me again... and the specs topic again too.
>>
>> I have been thinking about this for quite a while and I believe
>> that it would be in the best interest of the project to treat our
>> specs as a project and use one version to release the spec modules
>> under.
>>
>> Doing so will greatly reduce the complexity to maintain the specs
>> tree and to make new releases.  It also reduces the need for a
>> bunch of config in the root pom.xml for specs... all properties can
>> be removed and most of the dependencyManagement can be removed as
>> well.
>>
>> Releases can be done using the release plugin with out any twists
>> of configuration, which should be straight forward.  The
>> alternative is that the configuration becomes more compkicated and
>> that in order to make a release users will have to have much more
>> knowledge of how Maven works and how we have configured it... which
>> I am betting will only lead to something being missed which will
>> only lead to problems down the road.
>>
>> One thing to remember for those of you who are gonna say that some
>> spec module has not changed in x-years... is that the release is
>> code + pom configuration... and even if the code has not changed,
>> the configuration has, and thus it warrants a new release to be made.
>>
>> Specs do not get released that often anyways, so I don't really see
>> any huge problem with re-releasing specs under a new version when
>> something is added (or fixed).
>>
>> 1 version number for us (and our users) is IMO much, much simperer
>> than 30+ versions.  For example, if I am a developer and want to
>> use the latest versions of all of the specs that I use, I would
>> much rather know that there is just one version to track, instead
>> of needing to hunt down what the latest version of each spec is...
>> after all I don't care what the version is... I just want the
>> latest version.
>>
>> Also remember that some spec modules depend on other spec modules,
>> so ideally when a dependency module is released, the dependent
>> modules should be released to pickup the latest versions.  Doing
>> this is automatic with the one-version scheme, but becomes much
>> more work with independent versions... which will almost certainly
>> result in dependent modules not getting updated as they should.
>>
>>  * * *
>>
>> We have also been waiting for some resolution on this to simplify
>> the main server build.  It will take all of 10 minutes for me to
>> fix the specs build to use one version and make a release than can
>> be used by the server build (and allow the bootstrap of specs to be
>> removed).
>>
>> So, my recommendation is to:
>>
>>   1) change the specs project to use one version, 2.0-SNAPSHOT, and
>> publish the snaps
>>   2) update the server build to use 2.0-SNAPSHOT for all specs
>>   3) remove the specs build from bootstrap
>>
>> I believe this is the best option for the project and community at
>> this point.  I would like to implement this ASAP to simplify the
>> server build.  If after some time folks do not feel that is working
>> well, then we can revisit and consider either splitting up into a
>> multi-trunk build or using independent version numbers.  But, I do
>> believe that most will find that the advantages of using one
>> version far out-weight the disadvantages.
>>
>> NOTE:
>>
>> For those unaware, Dain did an experiment with version ranges...
>> but it looks like this will not work well right now as there is not
>> general support for use of ranges in most plugins that we depend
>> on.  Also several members of the m2 team have suggested that ranges
>> are buggy.  This was my general impression that I brought up to
>> Dain weeks ago when we talked about using ranges (and when he said
>> he would try it out).  So, for now at least I think that ranges
>> will not work for us.
>>
>> --jason
>>
>>
>

Re: One version for specs

[ja...@gmail.com]

Remeber now.... A release is jar + pom configuration. 

--jason


  

-----Original Message-----
From: "Alan D. Cabrera" <li...@toolazydogs.com>
Date: Mon, 2 Oct 2006 06:51:20 
To:dev@geronimo.apache.org
Subject: Re: One version for specs

I don't think that this is a good idea.  Versions should reflect the  
contents of the jar not the fact that an unrelated spec was released/ 
patched/updated.


Regards,
Alan

On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:

> Hi, me again... and the specs topic again too.
>
> I have been thinking about this for quite a while and I believe  
> that it would be in the best interest of the project to treat our  
> specs as a project and use one version to release the spec modules  
> under.
>
> Doing so will greatly reduce the complexity to maintain the specs  
> tree and to make new releases.  It also reduces the need for a  
> bunch of config in the root pom.xml for specs... all properties can  
> be removed and most of the dependencyManagement can be removed as  
> well.
>
> Releases can be done using the release plugin with out any twists  
> of configuration, which should be straight forward.  The  
> alternative is that the configuration becomes more compkicated and  
> that in order to make a release users will have to have much more  
> knowledge of how Maven works and how we have configured it... which  
> I am betting will only lead to something being missed which will  
> only lead to problems down the road.
>
> One thing to remember for those of you who are gonna say that some  
> spec module has not changed in x-years... is that the release is  
> code + pom configuration... and even if the code has not changed,  
> the configuration has, and thus it warrants a new release to be made.
>
> Specs do not get released that often anyways, so I don't really see  
> any huge problem with re-releasing specs under a new version when  
> something is added (or fixed).
>
> 1 version number for us (and our users) is IMO much, much simperer  
> than 30+ versions.  For example, if I am a developer and want to  
> use the latest versions of all of the specs that I use, I would  
> much rather know that there is just one version to track, instead  
> of needing to hunt down what the latest version of each spec is...  
> after all I don't care what the version is... I just want the  
> latest version.
>
> Also remember that some spec modules depend on other spec modules,  
> so ideally when a dependency module is released, the dependent  
> modules should be released to pickup the latest versions.  Doing  
> this is automatic with the one-version scheme, but becomes much  
> more work with independent versions... which will almost certainly  
> result in dependent modules not getting updated as they should.
>
>  * * *
>
> We have also been waiting for some resolution on this to simplify  
> the main server build.  It will take all of 10 minutes for me to  
> fix the specs build to use one version and make a release than can  
> be used by the server build (and allow the bootstrap of specs to be  
> removed).
>
> So, my recommendation is to:
>
>   1) change the specs project to use one version, 2.0-SNAPSHOT, and  
> publish the snaps
>   2) update the server build to use 2.0-SNAPSHOT for all specs
>   3) remove the specs build from bootstrap
>
> I believe this is the best option for the project and community at  
> this point.  I would like to implement this ASAP to simplify the  
> server build.  If after some time folks do not feel that is working  
> well, then we can revisit and consider either splitting up into a  
> multi-trunk build or using independent version numbers.  But, I do  
> believe that most will find that the advantages of using one  
> version far out-weight the disadvantages.
>
> NOTE:
>
> For those unaware, Dain did an experiment with version ranges...  
> but it looks like this will not work well right now as there is not  
> general support for use of ranges in most plugins that we depend  
> on.  Also several members of the m2 team have suggested that ranges  
> are buggy.  This was my general impression that I brought up to  
> Dain weeks ago when we talked about using ranges (and when he said  
> he would try it out).  So, for now at least I think that ranges  
> will not work for us.
>
> --jason
>
>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

I don't think that this is a good idea.  Versions should reflect the  
contents of the jar not the fact that an unrelated spec was released/ 
patched/updated.


Regards,
Alan

On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:

> Hi, me again... and the specs topic again too.
>
> I have been thinking about this for quite a while and I believe  
> that it would be in the best interest of the project to treat our  
> specs as a project and use one version to release the spec modules  
> under.
>
> Doing so will greatly reduce the complexity to maintain the specs  
> tree and to make new releases.  It also reduces the need for a  
> bunch of config in the root pom.xml for specs... all properties can  
> be removed and most of the dependencyManagement can be removed as  
> well.
>
> Releases can be done using the release plugin with out any twists  
> of configuration, which should be straight forward.  The  
> alternative is that the configuration becomes more compkicated and  
> that in order to make a release users will have to have much more  
> knowledge of how Maven works and how we have configured it... which  
> I am betting will only lead to something being missed which will  
> only lead to problems down the road.
>
> One thing to remember for those of you who are gonna say that some  
> spec module has not changed in x-years... is that the release is  
> code + pom configuration... and even if the code has not changed,  
> the configuration has, and thus it warrants a new release to be made.
>
> Specs do not get released that often anyways, so I don't really see  
> any huge problem with re-releasing specs under a new version when  
> something is added (or fixed).
>
> 1 version number for us (and our users) is IMO much, much simperer  
> than 30+ versions.  For example, if I am a developer and want to  
> use the latest versions of all of the specs that I use, I would  
> much rather know that there is just one version to track, instead  
> of needing to hunt down what the latest version of each spec is...  
> after all I don't care what the version is... I just want the  
> latest version.
>
> Also remember that some spec modules depend on other spec modules,  
> so ideally when a dependency module is released, the dependent  
> modules should be released to pickup the latest versions.  Doing  
> this is automatic with the one-version scheme, but becomes much  
> more work with independent versions... which will almost certainly  
> result in dependent modules not getting updated as they should.
>
>  * * *
>
> We have also been waiting for some resolution on this to simplify  
> the main server build.  It will take all of 10 minutes for me to  
> fix the specs build to use one version and make a release than can  
> be used by the server build (and allow the bootstrap of specs to be  
> removed).
>
> So, my recommendation is to:
>
>   1) change the specs project to use one version, 2.0-SNAPSHOT, and  
> publish the snaps
>   2) update the server build to use 2.0-SNAPSHOT for all specs
>   3) remove the specs build from bootstrap
>
> I believe this is the best option for the project and community at  
> this point.  I would like to implement this ASAP to simplify the  
> server build.  If after some time folks do not feel that is working  
> well, then we can revisit and consider either splitting up into a  
> multi-trunk build or using independent version numbers.  But, I do  
> believe that most will find that the advantages of using one  
> version far out-weight the disadvantages.
>
> NOTE:
>
> For those unaware, Dain did an experiment with version ranges...  
> but it looks like this will not work well right now as there is not  
> general support for use of ranges in most plugins that we depend  
> on.  Also several members of the m2 team have suggested that ranges  
> are buggy.  This was my general impression that I brought up to  
> Dain weeks ago when we talked about using ranges (and when he said  
> he would try it out).  So, for now at least I think that ranges  
> will not work for us.
>
> --jason
>
>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote:

> As a user, it is a convenience to be able to have a single version
> number to track across all the spec releases.  So there's only one
> variable to track.
>


There are two classes of specs users.  One is Geroninmo users and  
they will just use what ever we have configured; they will not need  
to track anything since we'll provide everything nicely configured.   
The second is someone outside of Geronimo who wants to use a spec  
jar.  This person will want to *not* want a single version tracking  
across all the spec releases.


Regards,
Alan

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote:
> However, I still don't think this is a very good approach.  Our specs
> tree will continue to expand with new JSRs and J2EE releases,
> especially if we go with the earlier intent of making it a home for
> all Apache Java spec packages.  I don't like the idea that I'll have
> 10 versions of EJB 2.0 in my local repository, all with the same code,
> and with different projects potentially using different revs depending
> on how aggressive they are about needing new unrelated specs.

Growing spec modules is actually a case to simplify and use one  
version rather than the opposite... especially for cases when new  
specs depend on other specs.


> I think in the end, I'd rather have separate builds for separate specs
> and an auto-generated or frequently updated web page with a table
> listing all the specs with their JSR reference and the latest released
> and snapshot versions of each.  If I had to check that page for the
> right numbers for each spec when building a new POM, that would be a
> pretty close second to just having all of them use the same number
> (which I'd still have to look up each time anyway).  And it would mean
> copy and paste dependencies on old specs like EJB 2 would be more
> likely to be up to date.

IMO the one-version for users, which is the point I am getting most  
of of this reply, is a side-effect of a simple process for developers  
(us) to manage a growing codebase of specs.

Separate builds for specs does not really solve any of the problems  
related to maintenance which I have been trying to explain in more  
detail.  The only problem which separate builds solves is that it  
reduces (not eliminates) re-releases of spec modules hat have had no  
_code_ change (could be a header change, or a config change, or a  
documentation change though).

The amount of effort required to maintain a system like this far  
outweighs the advantages of _purity_ (or semi-purity when you  
consider the non-code changes described above).

--jason

Re: One version for specs

[Aaron Mulder <am...@alumni.princeton.edu>]

As a user, it is a convenience to be able to have a single version
number to track across all the spec releases.  So there's only one
variable to track.

However, I still don't think this is a very good approach.  Our specs
tree will continue to expand with new JSRs and J2EE releases,
especially if we go with the earlier intent of making it a home for
all Apache Java spec packages.  I don't like the idea that I'll have
10 versions of EJB 2.0 in my local repository, all with the same code,
and with different projects potentially using different revs depending
on how aggressive they are about needing new unrelated specs.

I think in the end, I'd rather have separate builds for separate specs
and an auto-generated or frequently updated web page with a table
listing all the specs with their JSR reference and the latest released
and snapshot versions of each.  If I had to check that page for the
right numbers for each spec when building a new POM, that would be a
pretty close second to just having all of them use the same number
(which I'd still have to look up each time anyway).  And it would mean
copy and paste dependencies on old specs like EJB 2 would be more
likely to be up to date.

But in the end, I don't feel super-strongly about it.

Thanks,
      Aaron

On 10/1/06, Jason Dillon <ja...@planet57.com> wrote:
> Hi, me again... and the specs topic again too.
>
> I have been thinking about this for quite a while and I believe that
> it would be in the best interest of the project to treat our specs as
> a project and use one version to release the spec modules under.
>
> Doing so will greatly reduce the complexity to maintain the specs
> tree and to make new releases.  It also reduces the need for a bunch
> of config in the root pom.xml for specs... all properties can be
> removed and most of the dependencyManagement can be removed as well.
>
> Releases can be done using the release plugin with out any twists of
> configuration, which should be straight forward.  The alternative is
> that the configuration becomes more compkicated and that in order to
> make a release users will have to have much more knowledge of how
> Maven works and how we have configured it... which I am betting will
> only lead to something being missed which will only lead to problems
> down the road.
>
> One thing to remember for those of you who are gonna say that some
> spec module has not changed in x-years... is that the release is code
> + pom configuration... and even if the code has not changed, the
> configuration has, and thus it warrants a new release to be made.
>
> Specs do not get released that often anyways, so I don't really see
> any huge problem with re-releasing specs under a new version when
> something is added (or fixed).
>
> 1 version number for us (and our users) is IMO much, much simperer
> than 30+ versions.  For example, if I am a developer and want to use
> the latest versions of all of the specs that I use, I would much
> rather know that there is just one version to track, instead of
> needing to hunt down what the latest version of each spec is... after
> all I don't care what the version is... I just want the latest version.
>
> Also remember that some spec modules depend on other spec modules, so
> ideally when a dependency module is released, the dependent modules
> should be released to pickup the latest versions.  Doing this is
> automatic with the one-version scheme, but becomes much more work
> with independent versions... which will almost certainly result in
> dependent modules not getting updated as they should.
>
>   * * *
>
> We have also been waiting for some resolution on this to simplify the
> main server build.  It will take all of 10 minutes for me to fix the
> specs build to use one version and make a release than can be used by
> the server build (and allow the bootstrap of specs to be removed).
>
> So, my recommendation is to:
>
>    1) change the specs project to use one version, 2.0-SNAPSHOT, and
> publish the snaps
>    2) update the server build to use 2.0-SNAPSHOT for all specs
>    3) remove the specs build from bootstrap
>
> I believe this is the best option for the project and community at
> this point.  I would like to implement this ASAP to simplify the
> server build.  If after some time folks do not feel that is working
> well, then we can revisit and consider either splitting up into a
> multi-trunk build or using independent version numbers.  But, I do
> believe that most will find that the advantages of using one version
> far out-weight the disadvantages.
>
> NOTE:
>
> For those unaware, Dain did an experiment with version ranges... but
> it looks like this will not work well right now as there is not
> general support for use of ranges in most plugins that we depend on.
> Also several members of the m2 team have suggested that ranges are
> buggy.  This was my general impression that I brought up to Dain
> weeks ago when we talked about using ranges (and when he said he
> would try it out).  So, for now at least I think that ranges will not
> work for us.
>
> --jason
>
>
>

Re: One version for specs

[Kevan Miller <ke...@gmail.com>]

On Oct 1, 2006, at 7:31 PM, David Jencks wrote:

> After a long time thinking that separately versioned specs were  
> better I started thinking about how much work it would be if I was  
> trying to release separately versioned specs.  I now think we  
> should at least try the one-version approach.  What we've been  
> doing has resulted IMO in total confusion and many many problems  
> releasing specs.
>
> In any case PLEASE think about this and make your opinion known soon.
>
> My only caveat is that I would prefer to use 1.2-SNAPSHOT releasing  
> to 1.2 rather than 2.0.  I tend to regard this as finally  
> straightening out what we are doing with specs, and lining up the  
> versioning and release with the directory structure, rather than a  
> major policy change.  (now we have a policy rather than confusion :-)

I totally agree that 1 consisten spec version is the way to go.

I'd also prefer a 1.2, rather than a 2.0 release. However, I doubt  
that I would devote too many keystrokes arguing the point...

--kevan

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Oct 1, 2006, at 4:31 PM, David Jencks wrote:

> After a long time thinking that separately versioned specs were  
> better I started thinking about how much work it would be if I was  
> trying to release separately versioned specs.  I now think we  
> should at least try the one-version approach.  What we've been  
> doing has resulted IMO in total confusion and many many problems  
> releasing specs.

Can you elaborate what those problems were?


Regards,
Alan

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 1, 2006, at 4:31 PM, David Jencks wrote:

> I now think we should at least try the one-version approach.  What  
> we've been doing has resulted IMO in total confusion and many many  
> problems releasing specs.

We did try that, seven times.  M1 -> 1.0.1 had all specs released all  
at the same time with the same version number.

-David

Re: One version for specs

[David Jencks <da...@yahoo.com>]

Can we think carefully about complexity for a second and agree that  
the two models under discussion are

trunk/<individual specs at same SNAPSHOT version>
branches/<version>/<all the individual specs at that SNAPSHOT version>
tags/<version>/<all the individual specs at that non-SNAPSHOT version>


and
<each spec>/[trunk, branches/<version>, tags/<version>]

(in the 2nd choice each spec must be built and released individually  
by itself, there is no "build all the specs" pom)

and that any other choices are going to make releasing anything  
correctly 120% impossible?  We already have a system that doesn't  
work, thinking up more and more complicated choices is not going to  
result in ever releasing anything correctly.

I'll repeat that philosophically I prefer the second solution but I  
don't think we have the attention span as a project to make it work  
so I'm voting for the first choice.  I know if I was in charge of  
releasing the specs I would mess up the second choice for sure but I  
might be able to make the first choice work.  If only half the specs  
are in trunk I wouldn't even try to build the specs myself locally.

thanks
david jencks

On Oct 3, 2006, at 10:15 AM, David Blevins wrote:

>
> On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
>
>>
>> On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
>>
>>> The main problem with compromise in this case... (not that I am  
>>> unwilling to do so), is that it appears that _any_ compromise  
>>> results in the same problem which I am trying to lead us away  
>>> from.  That problem being a complicated build and release process  
>>> due to needing deep insight into the dependencies of each spec  
>>> (or in your example, the groups of specs).
>>
>> No, I wasn't advocating groups of specs.  Was more saying "let's  
>> just delete these specs from trunk" or otherwise get rid of them  
>> and leave only the specs that change and do the one version number  
>> thing.  The code is tagged, so it's safe.  Perhaps the issue is  
>> that we don't need these unchanging modules in trunk in the first  
>> place.  And just so you don't think I'm ignoring pom changes, the  
>> poms for the modules I listed are stable to (no deps on anything  
>> that's changed).
>>
>> Thoughts?
>
> Thoughts?
>
> Yank these from trunk as they haven't changed in 2+ years?
>
> ejb
> servlet
> jms
> transaction
> connector
> qname
>
>
> -David
>
>> -David
>>
>>>
>>> --jason
>>>
>>>
>>> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>>>
>>>>
>>>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>>>
>>>>> In any case PLEASE think about this and make your opinion known  
>>>>> soon.
>>>>
>>>> If we could at least make a compromise that'd be very great, all  
>>>> or nothing is not the only way.
>>>>
>>>> Maybe we could just remove these core specs from trunk or  
>>>> something (we have several tags):
>>>>
>>>>  ejb
>>>>  servlet
>>>>  jsp
>>>>  jms
>>>>  transaction
>>>>  connector
>>>>  qname
>>>>
>>>> If all the rest became "one version number" specs released at  
>>>> the pace of the most changing spec, that'd still be less  
>>>> desirable but be at least better.
>>>>
>>>> Maybe not the best idea, just trying to find some middle  
>>>> ground.  Thoughts?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

For the record, I just want the specs issue resolved... be it my way  
or not... I just want it fixed.

  * * *

I apologize to those who think I was ignoring them... this issue was  
getting me way to worked up and I had to basically delete the thread  
to clear my head.

--jason

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 3, 2006, at 11:47 AM, Jason Dillon wrote:

> On Oct 3, 2006, at 11:39 AM, David Blevins wrote:
>> Ok, now it's me whose not reading emails :)  You mentioned the  
>> site changes.  Is that it?   Are we really talking about re- 
>> releasing completely stable specs because of website changes?
>
> This was a reason why the spec module might change, not why (or why  
> not) it should be released.

Sure, but the proposal is that it would get released with just it's  
website changes whenever some other spec needs to be released because  
of code changes.

I'm not so concerned about website stuff for the core specs that  
don't change.  If that's the reason for wanting to keep updating the  
poms and re-releasing specs which are essentially "done", is there  
any other way we can meet the website goals you have?

-David


> --jason
>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

On Oct 3, 2006, at 11:39 AM, David Blevins wrote:
> Ok, now it's me whose not reading emails :)  You mentioned the site  
> changes.  Is that it?   Are we really talking about re-releasing  
> completely stable specs because of website changes?

This was a reason why the spec module might change, not why (or why  
not) it should be released.

--jason

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 3, 2006, at 11:25 AM, David Blevins wrote:

>
> On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote:
>
>> On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
>>> Dude, you never read my emails.
>>
>> I read it... but the mail you just sent said they have not changed:
>>
>
> Can you give some examples on what kind of pom changes that would  
> happen to these that would merit another release?

Ok, now it's me whose not reading emails :)  You mentioned the site  
changes.  Is that it?   Are we really talking about re-releasing  
completely stable specs because of website changes?

-David

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote:

> On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
>> Dude, you never read my emails.
>
> I read it... but the mail you just sent said they have not changed:
>

Can you give some examples on what kind of pom changes that would  
happen to these that would merit another release?

-David

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
> Dude, you never read my emails.

I read it... but the mail you just sent said they have not changed:

>> On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
>>> Yank these from trunk as they haven't changed in 2+ years?

--jason

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 3, 2006, at 10:50 AM, Jason Dillon wrote:

> On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
>> Thoughts?
>>
>> Yank these from trunk as they haven't changed in 2+ years?
>>
>> ejb
>> servlet
>> jms
>> transaction
>> connector
>> qname
>
> Not true... remember the pom.  Once all of this is settled we need  
> to update the site deployments too.  So it is not safe to assume  
> these will not change.

Dude, you never read my emails.

On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
> And just so you don't think I'm ignoring pom changes, the poms for  
> the modules I listed are stable to (no deps on anything that's  
> changed).

Waiting for another reply....

-David

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
> Thoughts?
>
> Yank these from trunk as they haven't changed in 2+ years?
>
> ejb
> servlet
> jms
> transaction
> connector
> qname

Not true... remember the pom.  Once all of this is settled we need to  
update the site deployments too.  So it is not safe to assume these  
will not change.

--jason

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 2, 2006, at 1:35 PM, David Blevins wrote:

>
> On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
>
>> The main problem with compromise in this case... (not that I am  
>> unwilling to do so), is that it appears that _any_ compromise  
>> results in the same problem which I am trying to lead us away  
>> from.  That problem being a complicated build and release process  
>> due to needing deep insight into the dependencies of each spec (or  
>> in your example, the groups of specs).
>
> No, I wasn't advocating groups of specs.  Was more saying "let's  
> just delete these specs from trunk" or otherwise get rid of them  
> and leave only the specs that change and do the one version number  
> thing.  The code is tagged, so it's safe.  Perhaps the issue is  
> that we don't need these unchanging modules in trunk in the first  
> place.  And just so you don't think I'm ignoring pom changes, the  
> poms for the modules I listed are stable to (no deps on anything  
> that's changed).
>
> Thoughts?

Thoughts?

Yank these from trunk as they haven't changed in 2+ years?

ejb
servlet
jms
transaction
connector
qname


-David

> -David
>
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>>
>>>
>>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>>
>>>> In any case PLEASE think about this and make your opinion known  
>>>> soon.
>>>
>>> If we could at least make a compromise that'd be very great, all  
>>> or nothing is not the only way.
>>>
>>> Maybe we could just remove these core specs from trunk or  
>>> something (we have several tags):
>>>
>>>  ejb
>>>  servlet
>>>  jsp
>>>  jms
>>>  transaction
>>>  connector
>>>  qname
>>>
>>> If all the rest became "one version number" specs released at the  
>>> pace of the most changing spec, that'd still be less desirable  
>>> but be at least better.
>>>
>>> Maybe not the best idea, just trying to find some middle ground.   
>>> Thoughts?
>>>
>>> -David
>>>
>>>
>>
>

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:

> The main problem with compromise in this case... (not that I am  
> unwilling to do so), is that it appears that _any_ compromise  
> results in the same problem which I am trying to lead us away  
> from.  That problem being a complicated build and release process  
> due to needing deep insight into the dependencies of each spec (or  
> in your example, the groups of specs).

No, I wasn't advocating groups of specs.  Was more saying "let's just  
delete these specs from trunk" or otherwise get rid of them and leave  
only the specs that change and do the one version number thing.  The  
code is tagged, so it's safe.  Perhaps the issue is that we don't  
need these unchanging modules in trunk in the first place.  And just  
so you don't think I'm ignoring pom changes, the poms for the modules  
I listed are stable to (no deps on anything that's changed).

Thoughts?

-David

>
> --jason
>
>
> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
>>
>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>
>>> In any case PLEASE think about this and make your opinion known  
>>> soon.
>>
>> If we could at least make a compromise that'd be very great, all  
>> or nothing is not the only way.
>>
>> Maybe we could just remove these core specs from trunk or  
>> something (we have several tags):
>>
>>  ejb
>>  servlet
>>  jsp
>>  jms
>>  transaction
>>  connector
>>  qname
>>
>> If all the rest became "one version number" specs released at the  
>> pace of the most changing spec, that'd still be less desirable but  
>> be at least better.
>>
>> Maybe not the best idea, just trying to find some middle ground.   
>> Thoughts?
>>
>> -David
>>
>>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

The main problem with compromise in this case... (not that I am  
unwilling to do so), is that it appears that _any_ compromise results  
in the same problem which I am trying to lead us away from.  That  
problem being a complicated build and release process due to needing  
deep insight into the dependencies of each spec (or in your example,  
the groups of specs).

IMO, splitting up into a smaller subset of groups for specs is no  
better than having a separate tree for each.

I do not believe that multi-versioned spec maintenance will scale  
well... and in some ways I think it has already kinda proven that.  3  
small groups for 1.4, 1.5 and other is already on the verge of  
becoming more work than it should be due to the overlap and  
dependencies.

I will even go as far as saying that for most large project multi- 
versioning will not scale.  Consider how much work it would be to  
keep G in sync if each and every module (config, code, app  
deployable, app deployable component, assembly and plugin) were  
individual versioned to live up to the code to version purity fallacy.

Well, I can tell you that is a massive nightmare in the works... I've  
been there already in fact, a few times, most recently at my last  
gig.  When I got there I saw developers with little stickys on their  
cubes listing versions and compatibility of like 60 different  
modules... where it took developers hours to make releases for each  
module, which ended up causing more problems if something was missed  
or a mistake was made that cascaded down to other dependent modules  
which ended up causing the entire thing to be re-released.  It took  
me almost 5 months to un*uck that mess (of which a lot of time was  
spent sending mails kinda like this one)... and in the end I left  
them in a state where they could automate *every* build and every  
release at the click of a button on a browser.  What used to take  
hours and caused a bunch of problems due to an overly complicated  
process to make a simple code release, could now be done in a few  
minutes and was highly reliable, repeatable and simple.

--jason


On Oct 2, 2006, at 11:16 AM, David Blevins wrote:

>
> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>
>> In any case PLEASE think about this and make your opinion known soon.
>
> If we could at least make a compromise that'd be very great, all or  
> nothing is not the only way.
>
> Maybe we could just remove these core specs from trunk or something  
> (we have several tags):
>
>  ejb
>  servlet
>  jsp
>  jms
>  transaction
>  connector
>  qname
>
> If all the rest became "one version number" specs released at the  
> pace of the most changing spec, that'd still be less desirable but  
> be at least better.
>
> Maybe not the best idea, just trying to find some middle ground.   
> Thoughts?
>
> -David
>
>

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:

> How about we split them into j2ee 1.4, j2ee 1.5 and independent  
> modules for the non j2ee specs?  This will prevent the flux from  
> the 1.5 development from causing lots of new versions for the 1.4  
> specs.
>
> Just another middle ground idea.  Thoughts?

There are a few specs that overlap and are used in both j2ee 1.4 and  
jee 5 such as jms and connector.  There might be more.

-David

> -dain
>
> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
>>
>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>
>>> In any case PLEASE think about this and make your opinion known  
>>> soon.
>>
>> If we could at least make a compromise that'd be very great, all  
>> or nothing is not the only way.
>>
>> Maybe we could just remove these core specs from trunk or  
>> something (we have several tags):
>>
>>  ejb
>>  servlet
>>  jsp
>>  jms
>>  transaction
>>  connector
>>  qname
>>
>> If all the rest became "one version number" specs released at the  
>> pace of the most changing spec, that'd still be less desirable but  
>> be at least better.
>>
>> Maybe not the best idea, just trying to find some middle ground.   
>> Thoughts?
>>
>> -David
>>
>>
>

Re: One version for specs

[Aaron Mulder <am...@alumni.princeton.edu>]

On 10/2/06, Dain Sundstrom <da...@iq80.com> wrote:
> How about we split them into j2ee 1.4, j2ee 1.5 and independent
> modules for the non j2ee specs?  This will prevent the flux from the
> 1.5 development from causing lots of new versions for the 1.4 specs.

Sounds promising to me...

Thanks,
    Aaron

> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
> >
> > On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
> >
> >> In any case PLEASE think about this and make your opinion known soon.
> >
> > If we could at least make a compromise that'd be very great, all or
> > nothing is not the only way.
> >
> > Maybe we could just remove these core specs from trunk or something
> > (we have several tags):
> >
> >  ejb
> >  servlet
> >  jsp
> >  jms
> >  transaction
> >  connector
> >  qname
> >
> > If all the rest became "one version number" specs released at the
> > pace of the most changing spec, that'd still be less desirable but
> > be at least better.
> >
> > Maybe not the best idea, just trying to find some middle ground.
> > Thoughts?
> >
> > -David
> >
> >
>
>

Re: One version for specs

[Jason Dillon <ja...@planet57.com>]

I don't think that 1.5 development will result in new releases...  
those will all be SNAPSHOT artifacts anyways.

Just some questions about this strategy...

Which modules go where?  Will each of these trees have a single  
version?  How will the overlap between J2EE 1.5 and 1.4 fit?  Where  
will common config go?

--jason


On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:

> How about we split them into j2ee 1.4, j2ee 1.5 and independent  
> modules for the non j2ee specs?  This will prevent the flux from  
> the 1.5 development from causing lots of new versions for the 1.4  
> specs.
>
> Just another middle ground idea.  Thoughts?
>
> -dain
>
> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
>>
>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>
>>> In any case PLEASE think about this and make your opinion known  
>>> soon.
>>
>> If we could at least make a compromise that'd be very great, all  
>> or nothing is not the only way.
>>
>> Maybe we could just remove these core specs from trunk or  
>> something (we have several tags):
>>
>>  ejb
>>  servlet
>>  jsp
>>  jms
>>  transaction
>>  connector
>>  qname
>>
>> If all the rest became "one version number" specs released at the  
>> pace of the most changing spec, that'd still be less desirable but  
>> be at least better.
>>
>> Maybe not the best idea, just trying to find some middle ground.   
>> Thoughts?
>>
>> -David
>>
>>
>

Re: One version for specs

[Prasad Kashyap <go...@gmail.com>]

A good compromise. Also, good for a start. Let's do this.

Cheers
Prasad

On 10/2/06, Dain Sundstrom <da...@iq80.com> wrote:
> How about we split them into j2ee 1.4, j2ee 1.5 and independent
> modules for the non j2ee specs?  This will prevent the flux from the
> 1.5 development from causing lots of new versions for the 1.4 specs.
>
> Just another middle ground idea.  Thoughts?
>
> -dain
>
> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
> >
> > On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
> >
> >> In any case PLEASE think about this and make your opinion known soon.
> >
> > If we could at least make a compromise that'd be very great, all or
> > nothing is not the only way.
> >
> > Maybe we could just remove these core specs from trunk or something
> > (we have several tags):
> >
> >  ejb
> >  servlet
> >  jsp
> >  jms
> >  transaction
> >  connector
> >  qname
> >
> > If all the rest became "one version number" specs released at the
> > pace of the most changing spec, that'd still be less desirable but
> > be at least better.
> >
> > Maybe not the best idea, just trying to find some middle ground.
> > Thoughts?
> >
> > -David
> >
> >
>
>

Re: One version for specs

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:

> How about we split them into j2ee 1.4, j2ee 1.5 and independent  
> modules for the non j2ee specs?  This will prevent the flux from  
> the 1.5 development from causing lots of new versions for the 1.4  
> specs.
>
> Just another middle ground idea.  Thoughts?

I have yet to hear about what the problem is that we're trying to  
solve by aggregating jars.


Regards,
Alan

Re: One version for specs

[Dain Sundstrom <da...@iq80.com>]

How about we split them into j2ee 1.4, j2ee 1.5 and independent  
modules for the non j2ee specs?  This will prevent the flux from the  
1.5 development from causing lots of new versions for the 1.4 specs.

Just another middle ground idea.  Thoughts?

-dain

On Oct 2, 2006, at 11:16 AM, David Blevins wrote:

>
> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>
>> In any case PLEASE think about this and make your opinion known soon.
>
> If we could at least make a compromise that'd be very great, all or  
> nothing is not the only way.
>
> Maybe we could just remove these core specs from trunk or something  
> (we have several tags):
>
>  ejb
>  servlet
>  jsp
>  jms
>  transaction
>  connector
>  qname
>
> If all the rest became "one version number" specs released at the  
> pace of the most changing spec, that'd still be less desirable but  
> be at least better.
>
> Maybe not the best idea, just trying to find some middle ground.   
> Thoughts?
>
> -David
>
>

Re: One version for specs

[David Blevins <da...@visi.com>]

On Oct 1, 2006, at 4:31 PM, David Jencks wrote:

> In any case PLEASE think about this and make your opinion known soon.

If we could at least make a compromise that'd be very great, all or  
nothing is not the only way.

Maybe we could just remove these core specs from trunk or something  
(we have several tags):

  ejb
  servlet
  jsp
  jms
  transaction
  connector
  qname

If all the rest became "one version number" specs released at the  
pace of the most changing spec, that'd still be less desirable but be  
at least better.

Maybe not the best idea, just trying to find some middle ground.   
Thoughts?

-David


  

Re: One version for specs

[David Jencks <da...@yahoo.com>]

After a long time thinking that separately versioned specs were  
better I started thinking about how much work it would be if I was  
trying to release separately versioned specs.  I now think we should  
at least try the one-version approach.  What we've been doing has  
resulted IMO in total confusion and many many problems releasing specs.

In any case PLEASE think about this and make your opinion known soon.

My only caveat is that I would prefer to use 1.2-SNAPSHOT releasing  
to 1.2 rather than 2.0.  I tend to regard this as finally  
straightening out what we are doing with specs, and lining up the  
versioning and release with the directory structure, rather than a  
major policy change.  (now we have a policy rather than confusion :-)

In addition I'd like to thank Jason for pushing on this issue.

thanks
david jencks

On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:

> Hi, me again... and the specs topic again too.
>
> I have been thinking about this for quite a while and I believe  
> that it would be in the best interest of the project to treat our  
> specs as a project and use one version to release the spec modules  
> under.
>
> Doing so will greatly reduce the complexity to maintain the specs  
> tree and to make new releases.  It also reduces the need for a  
> bunch of config in the root pom.xml for specs... all properties can  
> be removed and most of the dependencyManagement can be removed as  
> well.
>
> Releases can be done using the release plugin with out any twists  
> of configuration, which should be straight forward.  The  
> alternative is that the configuration becomes more compkicated and  
> that in order to make a release users will have to have much more  
> knowledge of how Maven works and how we have configured it... which  
> I am betting will only lead to something being missed which will  
> only lead to problems down the road.
>
> One thing to remember for those of you who are gonna say that some  
> spec module has not changed in x-years... is that the release is  
> code + pom configuration... and even if the code has not changed,  
> the configuration has, and thus it warrants a new release to be made.
>
> Specs do not get released that often anyways, so I don't really see  
> any huge problem with re-releasing specs under a new version when  
> something is added (or fixed).
>
> 1 version number for us (and our users) is IMO much, much simperer  
> than 30+ versions.  For example, if I am a developer and want to  
> use the latest versions of all of the specs that I use, I would  
> much rather know that there is just one version to track, instead  
> of needing to hunt down what the latest version of each spec is...  
> after all I don't care what the version is... I just want the  
> latest version.
>
> Also remember that some spec modules depend on other spec modules,  
> so ideally when a dependency module is released, the dependent  
> modules should be released to pickup the latest versions.  Doing  
> this is automatic with the one-version scheme, but becomes much  
> more work with independent versions... which will almost certainly  
> result in dependent modules not getting updated as they should.
>
>  * * *
>
> We have also been waiting for some resolution on this to simplify  
> the main server build.  It will take all of 10 minutes for me to  
> fix the specs build to use one version and make a release than can  
> be used by the server build (and allow the bootstrap of specs to be  
> removed).
>
> So, my recommendation is to:
>
>   1) change the specs project to use one version, 2.0-SNAPSHOT, and  
> publish the snaps
>   2) update the server build to use 2.0-SNAPSHOT for all specs
>   3) remove the specs build from bootstrap
>
> I believe this is the best option for the project and community at  
> this point.  I would like to implement this ASAP to simplify the  
> server build.  If after some time folks do not feel that is working  
> well, then we can revisit and consider either splitting up into a  
> multi-trunk build or using independent version numbers.  But, I do  
> believe that most will find that the advantages of using one  
> version far out-weight the disadvantages.
>
> NOTE:
>
> For those unaware, Dain did an experiment with version ranges...  
> but it looks like this will not work well right now as there is not  
> general support for use of ranges in most plugins that we depend  
> on.  Also several members of the m2 team have suggested that ranges  
> are buggy.  This was my general impression that I brought up to  
> Dain weeks ago when we talked about using ranges (and when he said  
> he would try it out).  So, for now at least I think that ranges  
> will not work for us.
>
> --jason
>
>