Hi Mark,
what the status of this proposal?
Do you have a JIRA-issue for it?
With the release of scm-1.7 I'd like to prepare a new release of the
m-release-p, so I'm just wondering what we should do here.
-Robert
Op Mon, 13 Feb 2012 22:46:53 +0100 schreef Mark Struberg
<strub...@yahoo.de>:
Hi maven folks!
I'm currently working on a fix for the ReleaseManager when doing a
release:perform with a sparse checkout using -DlocalCheckout=true.
We are already doing fine for DSCM (GIT, hg, ...) releases if you always
access the upstream repo. But this is not really git-like. 2 years ago I
hacked a quick fix to allow a local checkout with GIT (or other DSCMs)
by using a file file://${project.baseDirectory} URL instead.
The issue with this approach is that it doesn't work if the outermost
directory doesn't have any maven pom. We currently face this problem in
Apache DeltaSpike where we have multiple independent projects on the
outermost level in our GIT repo (site, build-tools, KEYS, etc ) in
addition to the project sources itself.
The outermost level doesn't contain any pom because we do not like to
have all those additional projects in our core source-release.
There are now 2 approaches to solve this issue.
a.) we could store the relative path info in the ReleaseDescriptor.
There is already a field named "scmRelativePathProjectDirectory" but
this seems to originally have been intended for a different purpose,
right? Is this still in use for that regard? Atm it get's set in the
shared CheckoutProjectFromScm phase. But this is obviously too late for
DSCMs when using localCheckout. Maybe we need a new parameter?
b.) In the CheckoutProjectFromScm phase we currently call
repository =
scmRepositoryConfigurator.getConfiguredRepository( releaseDescriptor,
releaseEnvironment.getSettings() );
provider = scmRepositoryConfigurator.getRepositoryProvider(
repository );
which will most probably cause an Exception if the repo URL doesn't
point to a valid SCM.
In this case we could itterarively cut down the last / part and re-try
to create the repo until we either hit consumed all parts of the SCM
repo URL (-> Exception) or we found a valid SCM repo.
any additional ideas?
From my gut feeling a.) is a bit cleaner, but much harder to implement.
b.) is pretty much a hack but should work fine and is easy to implement.
LieGrue,
strub
---------------------------------------------------------------------
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