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
