On Wed, Jun 27, 2012 at 2:42 AM, Jörg Schaible
<joerg.schai...@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-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

Reply via email to