geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: One version for specs
Date Tue, 03 Oct 2006 16:27:25 GMT
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 <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