aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Re: Aries releases - oh, the misery
Date Mon, 26 Mar 2012 08:50:27 GMT
I guess another disadvantage of the version plugin approach is that it  
would use the most recent version of *everything*, not just the Aries  
dependencies. We could possibly live with that in a build which is  
being used for testing, and not for producing manifests, but it's a  
bit icky.

On 25 Mar 2012, at 22:41, David Jencks <> wrote:

> Hi Holly
> I sure didn't think of that :-)
> I don't like it because there's no record in svn of what you  
> actually built with.  I do envisage using the versions plugin to  
> update the snapshots profile, although I don't recall checking to  
> see if it worked "inside" a profile.
> I also think, as I think you hinted, that it's going to be really  
> confusing on a developers machine to remember what state the pom is  
> in.  If you want to make a change to a pom and try both profiles  
> before committing I think you'll have a hard time reverting just the  
> version changes and keeping the ones you mean.
> thanks
> david jencks
> On Mar 25, 2012, at 1:55 PM, Holly Cummins wrote:
>> Hi,
>> I've been thinking more about the profiles for released versions and
>> snapshots. David J. has suggested maintaining profiles for released
>> versions and snapshots so we can accommodate both the requirement for
>> independently releasable modules, and the requirement that a  
>> current slice
>> across all modules had better work (

>> ).
>> David J., what was the reason for using a profile rather than the  
>> versions
>> plugin? I'm thinking of using something like the following to build  
>> with
>> snapshot versions:
>> mvn clean versions:use-latest-versions install
>> It seems like it would be much simpler than profiles, because we  
>> wouldn't
>> have to maintain any profiles.
>> I guess one downside is that such an invocation would work great in a
>> Jenkins environment, where there was no plan to commit things back,  
>> but it
>> would be lousy in a developers' sandbox, where the changes made by  
>> the
>> versions plugin get mixed in with other changes, and we'd have to  
>> be very
>> careful not to commit them by doing versions:revert. Other than that
>> objection, were there other downsides?
>> Holly
>> On Mon, Mar 5, 2012 at 12:30 AM, David Jencks  
>> <>wrote:
>>> re the idea of profiles for dependencies at released versions and
>>> snapshots (ARIES-798) -- I tried this out, it is very easy to set  
>>> up, but
>>> IIRC I got no feedback one way or another.  I still think it's a  
>>> good idea
>>> and am happy to set it up on the rest of the aries subprojects if  
>>> people
>>> like it.
>>> david jencks
>>> On Mar 4, 2012, at 8:22 AM, Holly Cummins wrote:
>>>> Hi all,
>>>> A while ago we were discussing the long-anticipated JPA release,  
>>>> and I
>>>> mentioned that I'd try and do a bug-fix release of the
>>> transaction-wrappers
>>>> bundle to try and get my feet wet with the release process.
>>>> Well, I've had a try, and I'm now feeling rather sodden, if not  
>>>> actually
>>>> drowned. I hate to re-open the subject of releases, since it's a  
>>>> bit of a
>>>> dead horse, but I think we're going to have continuing release  
>>>> issues*
>>>> until we do two things:
>>>> 1. Move to a 1.0 release. Until we do this, we can't have proper  
>>>> semantic
>>>> versioning, because we've cut off part of the version range and  
>>>> therefore
>>>> overloaded other parts of the range. It's ambiguous whether a  
>>>> change from
>>>> 0.4 to 0.5 is a breaking change or not. We used to version our  
>>>> internal
>>>> package imports as [0.x,1.0), but we hit problems on our last  
>>>> batch of
>>>> releases where bundles accepted incompatible versions of their
>>>> dependencies. Now we tend to lock everything down to the next minor
>>>> increment. This means that when a bundle is released, released  
>>>> versions
>>> of
>>>> bundles which depended on it no longer resolve with the new  
>>>> packages, and
>>>> must themselves be re-released.
>>>> 2. Be consistent in whether we depend on released versions or the  
>>>> latest
>>>> snapshots in our poms. Otherwise we aggravate the problem caused by
>>>> incomplete semantic versioning and end up having to release an even
>>> bigger
>>>> web of bundles per release. We discussed this in December (
>>>> ), and David Jencks raised ARIES-798 to cover creating profiles  
>>>> to allow
>>> us
>>>> to switch between released and snapshot versions.It looks to me  
>>>> like
>>> David
>>>> started but then decided the problem was just too hard - is that  
>>>> right,
>>>> David? At the moment we have a mix of snapshot and released  
>>>> dependencies
>>>> which makes it pretty hard to work out where we actually need a  
>>>> snapshot,
>>>> and where we're just using the latest and greatest to ensure test
>>> coverage
>>>> As a case study, let me explain what I've hit trying to release
>>>> transaction-wrappers, a very boring bundle with only two  
>>>> dependencies,
>>>> aries.util and aries.transaction.manager. Both are snapshot  
>>>> dependencies,
>>>> but I know by code inspection the transaction wrappers bundle  
>>>> will work
>>>> fine with the released versions. However, if I move to the released
>>>> versions, things rapidly unravel.
>>>> In particular, moving to the released util bundle leads to test  
>>>> failures
>>> in
>>>> the transaction itests. What's happening is that if I use
>>>> org.apache.aries.util-0.4 as my pom dependency, the itests use  
>>>> the 0.4
>>> util
>>>> bundle for testing. All of the other transactions bundles have a
>>> dependency
>>>> on 0.5-SNAPSHOT, so none of them will resolve. As far as I can  
>>>> see, I
>>> have
>>>> three options.
>>>> A. Identify by code inspection that none of the transaction bundles
>>>> actually need util-0.5, and revert to using released dependencies  
>>>> for the
>>>> whole transaction component. However, see point 2 above - since we
>>> declare
>>>> a dependency on the snapshot, it's pretty tedious to work out  
>>>> whether
>>> this
>>>> is a 'real' dependency or one which was done for ease of testing.
>>>> Furthermore, the changes to snapshot levels were introduced in  
>>>> ARIES-820,
>>>> as part of a general move to snapshot dependencies on util. So I  
>>>> can back
>>>> out the parts of ARIES-820 which relate to the transactions  
>>>> bundles.
>>> Sadly,
>>>> this just deepens the hole. I then have to do lots of tinkering to
>>> increase
>>>> the upper range of the util packages imported by the transactions
>>> bundles,
>>>> or tests in other components (which use util-0.5) will fail. Even  
>>>> to get
>>> a
>>>> set of bundles for the transactions itests which can resolve  
>>>> against
>>> means
>>>> changing dependencies in areas like blueprint-core.
>>>> B. Make the minimal change. After trying to do option A, this is  
>>>> pretty
>>>> appealing. Since I know transaction-wrappers works against  
>>>> util-0.4, all
>>> I
>>>> need to do is depend on util-0.4, but test with util-0.5 in the  
>>>> itests.
>>> The
>>>> downside is that this leaves a bit of a testing hole, but the
>>> combinatorics
>>>> of testing against every version we declare we support are  
>>>> intimidating.
>>>> However, it also means hard-coding versions, having bundle-specific
>>>> policies for what package versions of org.apache.aries.util we  
>>>> import,
>>> and
>>>> hacking around with pax-exam to persuade it not to test with the  
>>>> minimum
>>>> versions of the declared dependencies. It feels pretty icky, and  
>>>> it's a
>>> bit
>>>> of a band-aid.
>>>> C. Realise that any release involving bundles with a dependency on
>>> util-0.5
>>>> is going to have the exact same issues I'm seeing. Since pretty  
>>>> much
>>> every
>>>> component depends on util-0.5, stop trying to release
>>> transaction-wrappers
>>>> and just release util-0.5 first. This means everything can move  
>>>> back to
>>>> depending on the released version of util-0.5, and future  
>>>> releases should
>>>> be easier - sort of. Once some released bundles depend on  
>>>> util-0.5, no
>>>> bundle which depended on util-0.4 will resolve, so we'll actually  
>>>> just
>>> need
>>>> to release the whole project and abandon release-by-bundle for the
>>> moment.
>>>> I think we're going to continue seeing problems like this as long  
>>>> as we
>>>> have to keep our package imports locked down to minor increments  
>>>> (because
>>>> of point 1), and as long as we have snapshot dependencies  
>>>> scattered all
>>>> over the place (point 2).
>>>> Have we got a roadmap for moving to a 1.0 release? I guess it's  
>>>> too big a
>>>> job to be practical on a short timescale, but it will save time  
>>>> and make
>>>> life easier for our consuming projects once we get there, so it  
>>>> might be
>>>> worth keeping our eye on that goal.
>>>> Holly
>>>> * Or rather, we won't have independently releasable bundles

View raw message