On Fri, Apr 24, 2009 at 3:20 PM, Paul Gier <pg...@redhat.com> wrote: > Mark Struberg wrote: >> >> Hi! >> >> I thought in a similar direction. I think we can even let the maven-scm as >> it is. >> The problematic usecase is if we have a multi-module build and like to >> release only one of the sub modules. >> >> John Casey prepared an example for this use case: >> $> git-clone http://www.commonjava.org/gitroots/git-release-test.git >> To test the release plugin you need to clone it locally a 2nd time via >> file:// and then work in this 2nd checkout directory. >> >> >> There are 2 issues in this area >> >> 1.) I personally find it unaesthetic but I can live with it that a tag in >> git always counts for the whole project. So it is impossible to only tag a >> single sub-module - the tag will always be visible for all modules. In >> praxis this doesn't hurt because different tags should have different names >> anyway. >> >> 2.) A 'checkout' from a remote repository in git always requires a >> git-clone of that very repo first. This is regardless of having a tag on the >> whole project or if there would be a way to only stamp a part of the tree. >> So, as Brian already said, for mvn release:perform we first have to somehow >> find the proper submodule in target/checkout/.. before we run the whole >> test, site, deploy etc. Therefor I think we don't need to change maven-scm >> but 'only' the release-manager of the release-plugin. Finding the proper >> project dir may be done by finding all pom.xml [a] and looking for the >> correct groupId/artifactId [b]. >> >> As far as I've read this problem also affects other SCMs like accurev etc, >> isn't? Any users/devs of those SCMs here who may review if this solution >> would work for you too? >> >> txs and LieGrue, >> strub >> >> >> a) what if the pom.xml has a different name? Is this yet supported by the >> release plugin anyway? >> b) anyone has a better idea to find the right project directory? >> >> LieGrue, >> strub >> > > Is sounds like the process used by our release plugin doesn't really match > the way git works, so maybe we can change the way the release plugin works > instead of trying to fit git into our model. Do we really need to do a > clean checkout from the tag? Git must have a way to just check that the > local working copy is exactly the same as the tag on the server, right? As > long as we have a good way to verify that what we have locally matches > what's on the server, I don't think it's absolutely necessary to do a clean > checkout.
this goes to the heart of the major problem with code provenance which needs to address when considering GIT for a permissively licensed project. how can the provenance of a release be understood unless a canonical version history is available for that release? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
