+1 on going 3.1.0. At least, alphas is surely a too "frightening" name for many people to try it. Maybe RC would be more seen as already usable by a larger part of the community, but not sure it's worth the effort/debate.
Cheers 2013/6/24 Sievers, Jan <jan.siev...@sap.com> > >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 [1] > > 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. > > Regards, > Jan > > [1] http://wiki.eclipse.org/Tycho/Release_Notes/0.19 > > -----Original Message----- > From: Jason van Zyl [mailto:ja...@tesla.io] > 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 <vincent.lato...@gmail.com> > wrote: > > > OK, thanks for the clarification. > > Vincent > > > > > > 2013/6/22 Jason van Zyl <ja...@tesla.io>: > >> > >> On Jun 21, 2013, at 11:48 PM, Vincent Latombe < > vincent.lato...@gmail.com> 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 <joerg.schai...@scalaris.com> > >>>> > >>>> 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 > in > >>>>> 2.2.1 as well: > >>>>> > >>>>> https://gist.github.com/jvanzyl/5824206 > >>>> > >>>> 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 > years > >>>> old): > >>>> > >>>> https://gist.github.com/joehni/6aa8516bd5408144ec53 > >>>> > >>>> 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. In > >>>> 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 bug > >>>> 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 two > >>>> 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 I > >>>> already learned something new. > >>>> > >>>> Cheers and thanks for your time, > >>>> Jörg > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> Thanks, > >> > >> Jason > >> > >> ---------------------------------------------------------- > >> Jason van Zyl > >> Founder & CTO, Sonatype > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> --------------------------------------------------------- > >> > >> 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: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > Three people can keep a secret provided two of them are dead. > > -- Benjamin Franklin > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
