geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: One version for specs
Date Tue, 03 Oct 2006 18:09:58 GMT
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 <jason@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
>>> >>
>>> >>
>>> >
>>>
>>>
>


Mime
View raw message