maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sievers, Jan" <>
Subject RE: Maven 3.1.0-beta-1
Date Mon, 24 Jun 2013 07:49:44 GMT
>Almost zero people have given feedback 

tycho has recently adapted to the changes in maven 3.1.0-alpha-1 with version 0.19.0-SNAPSHOT

All our ITs are passing with maven 3.1.0-alpha-1 and we didn't get tycho bugs reported w.r.t.
maven 3.1.0-alpha-1
Not sure how many people are using it though so you may be right that maven 3.1.x needs more
advertising in order to to find the remaining issues.



-----Original Message-----
From: Jason van Zyl [] 
Sent: Sonntag, 23. Juni 2013 17:08
To: Maven Developers List
Subject: Re: Maven 3.1.0-beta-1

I'm just going to cut the 3.1.0. Almost zero people have given feedback and I don't think
anyone is going to look at this until it's released and then I think all sort of issues are
going to surface and I will prepare to fix those. I believe there will be many issues but
this process isn't going to find them.

On Jun 22, 2013, at 7:20 AM, Vincent Latombe <> wrote:

> OK, thanks for the clarification.
> Vincent
> 2013/6/22 Jason van Zyl <>:
>> On Jun 21, 2013, at 11:48 PM, Vincent Latombe <> wrote:
>>> Hello,
>>> I have a question about the alpha-1 release. I see that Aether has
>>> been updated to 0.9.0 M2.
>>> Does it implies that issue MNG-2802 (Concurrent-safe access to local
>>> Maven repository) is now implemented ?
>> No, it does not.
>>> If this is the case, then IMHO this should be mentioned, even
>>> highlighted in the release notes. I think this kind of improvement is
>>> very expected for all people doing CI, as this would allow a major
>>> speed up and reduce storage for local repositories in this kind of
>>> environment.
>>> Cheers,
>>> Vincent
>>> 2013/6/21 Jörg Schaible <>
>>>> Hi Jason,
>>>> first, thanks that you actually take your time to look into it!
>>>> Jason van Zyl wrote:
>>>>> I unpacked your example and ran your preparation script and it fails
>>>>> 2.2.1 as well:
>>>> The submodules are independent projects, you have to run "clean install".
>>>> See the following session (I have modified the POMs of the children by
>>>> adding a "<relativePath/>" element, the original example is now ~2
>>>> old):
>>>> Note, that after a successful run with M221, the build with M3x will no
>>>> longer fail, but pack stale snapshots. To raise an error, you have to clean
>>>> the repo from snapshots in <repohome>/bugs/maven.
>>>>> What's the overall usecase? You have a build with snapshots and you find
>>>>> you need to go back to a release so you lock down to a previous release
>>>>> and want to use that?
>>>> The final distribution of our product or projects typically consists of
>>>> hundreds of artifacts, where most of them have individual release cycles.
>>>> the HEAD revision those are linked in a nested directory structure using
>>>> "builder POMs" i.e. POMs that have only modules declared, but get never
>>>> released themselves (like the POM in the root of the example). The versions
>>>> of the individual artifact are managed in a shared parent POM. In HEAD those
>>>> are typically all snapshot versions.
>>>> This changes after a major release of the overall product, then all those
>>>> versions become final, the shared parent is released first followed by all
>>>> other artifacts in dependency order using this released parent. This works
>>>> all fine.
>>>> Now we get into maintenance mode of that major release. Due to the
>>>> independence of the artifacts we have to branch only the affected projects
>>>> in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop
>>>> fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C
>>>> and JAR-S to snapshot and also the artifacts that will assemble those to
>>>> jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance
>>>> branch that contains those jars, the war and the distribution zip as module.
>>>> Building this we should get a war that contains JAR-C and JAR-S as snapshot
>>>> and all the others as release and the distribution contains the affected
>>>> WAR-X as snapshot and all other stuff as released version - the perfect
>>>> situation to test the fix.
>>>> Unfortunately M3 fails here, because it is under some circumstance not able
>>>> to calculate the proper build order (maybe it does no longer take attached
>>>> snapshot artifacts into account ?!?) and will either pack a stale snapshot
>>>> from the local repository or fail, because the snapshot is built at a later
>>>> time.
>>>>> If you want to iteratively work on it together put it in a github repo.
>>>> If you bear with me, may day-to-day work is with svn only and my learning
>>>> curve with git/github is still steep, e.g. I did not know about gists, so
>>>> already learned something new.
>>>> Cheers and thanks for your time,
>>>> Jörg
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> ---------------------------------------------------------
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>  -- Jakob Burckhardt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message