Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=S9tn90Cj+gfo07N3iXLqQr4RiYjtNxAkOAs0I0ROLG1qCz1iYNsmpio9nSizmxkNwXRft5TOrxOH4ip6xydL/Ti5Ia4QzKSp4oPRGAdn5QABlr9dtJoGWExw41DkPvjYfVnExAgXHvt18YAqe1ECynOszDBMmBBW5Dq/8Im2Tto=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <74e15baa0610021338i6193d941t1a67f6719d6742f0@mail.gmail.com>
References: <77D3BF90-B687-4DD8-A7EF-260828356870@planet57.com>
 <2A52B452-ED6C-4934-A44F-DB60586C8D1C@toolazydogs.com>
 <BA954489-358C-4ED9-A6FC-7EE001087325@planet57.com>
 <74e15baa0610021338i6193d941t1a67f6719d6742f0@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A4F8056C-19C7-4533-B4D6-18719A239D8C@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: One version for specs
Date: Mon, 2 Oct 2006 14:03:06 -0700
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

You may be right... but I still believe one version is going to be  
easier for us.  And I am willing to make the changes to get one  
version working as it is simple and easy (with a decent network  
connection it can all be done in under an hour).

Almost anything else is going to take much longer and I believe the  
comparison of the work to rectify the state of the specs build is  
indicative of the effort it is going to take to maintain more and  
more of em.

But... we need to fix this.  Right now we can not even publish new  
specs for development as half of them will end up published to the  
snapshot repo and another half to the sync repo.  This is due to the  
versions in trunk not being reset to SNAPSHOT versions after a  
release... which is also some more evidence that the multi-version  
method is problematic as non of the versions in trunk should have  
been set to a non-SNAPSHOT for more than a brief moment when a  
release was being made.

With one version and the release plugin this problem goes away, and  
any dependencies are automatically updated to the correct version...  
which means that everything will be insync... all the time... at the  
slight cost of re-publishing new artifacts for modules which have had  
no code change... a minor cost worth the price of easy maintainable  
automation.

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