See MRELEASE-740.
It already works on Linux/Mac, but it seems to have a few issues on Win boxes.
I'm atm hanging on an openjpa issue I need in my company and will then fix the
few outstanding issues with MRELEASE-740.
Guess I will find time tomorrow evening.
After that, I'd hope we can get a release out of the door soon.
LieGrue,
strub
----- Original Message -----
> From: Robert Scholte <apa...@sourcegrounds.com>
> To: Maven Dev <dev@maven.apache.org>; Mark Struberg <strub...@yahoo.de>
> Cc:
> Sent: Sunday, April 29, 2012 11:11 PM
> Subject: Re: [RELEASE] sparse release:perform with DSCM and
> -DlocalCheckout=true
>
> 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
