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 --- Brian Fox <bri...@infinity.nu> schrieb am Fr, 24.4.2009: > Von: Brian Fox <bri...@infinity.nu> > Betreff: Re: Using GIT as the canonical repository for Maven 3.x > An: dev@maven.apache.org > Datum: Freitag, 24. April 2009, 1:21 > > > Mark Struberg wrote: > > technically there is no git repo which is 'better' > than the other. This hierarchy is an orga one. > > If you can pull from my repo and from Jasons, from > whom will you pull your master mainly? Bet you will pull > from Jasons. And I also bet all contributors will try to get > their changes being pulled by Jason and published in his > repo at the end of the day. > > > > > I think the canonical one would be equivalent to the > current svn, where committers have access to push in > changes. This would be required to maintain the "code > provenance" but it would still make everyone's life easier > to make changes and contribute them...and our lives easier > to apply them. > > > >> > Does Maven SCM support *fully* GIT? > >> > > mvn release:prepare and release:perform is working > with git since more than a year now. > > > I think this is slightly misleading.... > > The only uncertain point is how we should handle > multi-module builds. > Here's the rub. I talked with John after his chat with you > on IRC. It seems to be that the git scm actually clones the > repo from the tag to /target/checkout. (this is done because > an actual checkout would replace the current working folder > out from under the running maven...not good either). The > problem is that a git tag is a tag of the whole repo, so the > target/checkout contains everything, not just the submodule > being released. Maven would need to know this and step into > the correct folder before executing the perform build. > > Naturally this is a break from previous checkout based scm > systems. The proper fix (purely on speculation...i haven't > looked at the code in a long time) seems to be to allow the > scm provider to calculate the correct path for execution > given a working copy. In svn's case, it would simply return > target/checkout, in git's case it would be either > target/checkout or target/checkout/xxxxx based on how the > repo was constructed. > > This change would likely require an update to the > interface, the release plugin and the current scm wagons. > Any takers? I'll probably dabble in it myself if I can find > some time. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
