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:26:09 GMT
For the two classes of users that I mentioned earlier, the work will  
not be significant.  I'm not certain that the post-it note spectre  
applies to this narrow domain.


Regards,
Alan


On Oct 3, 2006, at 11:14 AM, Jason Dillon wrote:

> 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