On 12/12/2008, at 5:47 PM, Jason van Zyl wrote:
Sent from my iPhone
On Dec 12, 2008, at 7:02 AM, Brett Porter <[email protected]> wrote:
Hi,
I was looking at applying the patch for this one, but wasn't happy
with it and looked for a better solution, which I'm also not happy
with :)
Basically, in the reactor target/classes is always used as the
classpath for projects referring to dependencies inside the reactor
because of the way it is set in MavenProject. I think it would be
worth us reversing the logic in MavenProject (if the artifact file
is not null, use that, if it is, use the active project) - any
thoughts why that would be a bad idea?
The reactor, if only defined by what it has always been, means
resolving from the stated build output directory. You can't change
that fundamental contract at this point. How people work from the
reactor and/or walk into directories will yield a random mixture of
artifact and build output directories which I can only see causing
problems.
This isn't the entire reactor, but the getClasspathElements() method.
The only situation I can think of this breaking is:
* someone trying to pull apart the classpath looking for directories
and doing something special with them (which would be a horrible abuse
of the method's contract)
* someone modifying the outputDirectory after packaging and expecting
those changes to stick (a more realistic scenario but still one that
seems unwise to support)
It would seem more important to support the case of modifications to
the final artifact that are not reflected in the target/classes
directory (essentially what shade does, but others may as well). Not
terribly important, but this could still be a change that suits a 2.1+
release IMO.
As for shade, to make it work in the reactor, there's 3 options:
Trying to use the shade plugin from the reactor is a misuse of the
plugin. I specifically made it to work with JARs and it reads
entries from JARs.
I'm not quite sure what you mean here. The shade plugin is replacing
the main artifact with the one it produced, but not reflecting that
change in the reactor so others are not using. This is the default
mode for the shade plugin, not some obscure use case.
I would suggest treating the über JAR like an assembly where you
have a separate project.
That's what I've recommended in the mean time.
Thanks,
Brett
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
