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
