You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Struberg <st...@yahoo.de> on 2012/02/13 22:46:53 UTC
[RELEASE] sparse release:perform with DSCM and -DlocalCheckout=true
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RELEASE] sparse release:perform with DSCM and -DlocalCheckout=true
Posted by Mark Struberg <st...@yahoo.de>.
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 <ap...@sourcegrounds.com>
> To: Maven Dev <de...@maven.apache.org>; Mark Struberg <st...@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
> <st...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RELEASE] sparse release:perform with DSCM and
-DlocalCheckout=true
Posted by Robert Scholte <ap...@sourcegrounds.com>.
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
<st...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org