Sent from my [rhymes with myPod] ;-)
On 24 Apr 2009, at 14:32, Mark Struberg <strub...@yahoo.de> 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?
the second issue for accurev is that you cannot check out a workspace
into any path that starts with a path to which any other workspace has
been checked out... so if you are in /home/Connolly/work/foobar you
cannot check out the snapshot to /home/Connolly/work/foobar/target/
checkout, you'd have to find a folder that has not been used for any
other workspace from any other depot, check out to that folder and
then move it to target/checkout
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?
isn't the scm tag supposed to give you the relative path to the pom's
parent folder?
could we not just parse the scm URL to get the git root relative path
to the pom
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
