geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 21:56:07 GMT
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


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 <> 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
>> >>
>> >>
>> >

View raw message