> Do we really need to do a clean checkout from the tag? I'd strongly recommend it!
The main problems here are files which aren't checked in or ignored but somehow affect the compile or test outcome. This may imho only be guaranteed by a clean checkout into a separate directory. > process doesn't really match the way git works I have the gut feeling that there are quite a few SCMs out there (accurev, hg, PVCS, git,..) which work that way and they only got not enough love yet ;) LieGrue, strub --- Paul Gier <[email protected]> schrieb am Fr, 24.4.2009: > Von: Paul Gier <[email protected]> > Betreff: Re: Using GIT as the canonical repository for Maven 3.x > An: "Maven Developers List" <[email protected]> > Datum: Freitag, 24. April 2009, 16:20 > 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
