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
