geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 20:38:14 GMT
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

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.


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