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 18:14:20 GMT
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 <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