MSHADE-123: call for help

[Benson Margulies <bi...@gmail.com>]

Folks,

I've dug a hole (reported by) MSHADE-123 and I don't know what to do about this.

I dug the hole via the changes to move the default location of the
dependency reduced pom from the project basedir to target. Having the
drp in the basedir led to chaos when multiple builds ran in parallel
(all set with distinct output directories).

MavenProject.java defines getBasedir() to be the containing dir of the
pom, period. So if the drp isn't in the base dir, anything that runs
after shade is going to get an unpleasant surprise if it tries to use
${basedir} for something.

One possibly mitigation would be to set the default for the drp back
to the basedir, so that only crazy people like me would move it
someplace else.

A bigger fix would be to change MavenProject.java to allow an explicit
setting of basedir to be someplace other than where the pom lives.
Then shade could set it to the original basedir.

Thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: MSHADE-123: call for help

[Benson Margulies <bi...@gmail.com>]

On Wed, Jun 27, 2012 at 2:42 AM, Jörg Schaible
<Jo...@scalaris.com> wrote:
> Benson Margulies wrote:
>
>> Folks,
>>
>> I've dug a hole (reported by) MSHADE-123 and I don't know what to do about
>> this.
>>
>> I dug the hole via the changes to move the default location of the
>> dependency reduced pom from the project basedir to target. Having the
>> drp in the basedir led to chaos when multiple builds ran in parallel
>> (all set with distinct output directories).
>>
>> MavenProject.java defines getBasedir() to be the containing dir of the
>> pom, period. So if the drp isn't in the base dir, anything that runs
>> after shade is going to get an unpleasant surprise if it tries to use
>> ${basedir} for something.
>>
>> One possibly mitigation would be to set the default for the drp back
>> to the basedir, so that only crazy people like me would move it
>> someplace else.
>>
>> A bigger fix would be to change MavenProject.java to allow an explicit
>> setting of basedir to be someplace other than where the pom lives.
>> Then shade could set it to the original basedir.
>>
>> Thoughts?
>
> What about creating a copy of the project beneath target (or target/reduced)
> instead? Similar to the action of the release plugin using target/checkout.
>

Well, any rel paths anywhere in the project that reach outside the
project would then fail, since I don't see how we'd catch them all.
That might be better than the alternatives.


> Just an idea.
>
> - Jörg
>
>
>
> ---------------------------------------------------------------------
> 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: MSHADE-123: call for help

[Jörg Schaible <Jo...@scalaris.com>]

Benson Margulies wrote:

> Folks,
> 
> I've dug a hole (reported by) MSHADE-123 and I don't know what to do about
> this.
> 
> I dug the hole via the changes to move the default location of the
> dependency reduced pom from the project basedir to target. Having the
> drp in the basedir led to chaos when multiple builds ran in parallel
> (all set with distinct output directories).
> 
> MavenProject.java defines getBasedir() to be the containing dir of the
> pom, period. So if the drp isn't in the base dir, anything that runs
> after shade is going to get an unpleasant surprise if it tries to use
> ${basedir} for something.
> 
> One possibly mitigation would be to set the default for the drp back
> to the basedir, so that only crazy people like me would move it
> someplace else.
> 
> A bigger fix would be to change MavenProject.java to allow an explicit
> setting of basedir to be someplace other than where the pom lives.
> Then shade could set it to the original basedir.
> 
> Thoughts?

What about creating a copy of the project beneath target (or target/reduced) 
instead? Similar to the action of the release plugin using target/checkout.

Just an idea.

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org