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 ?
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
