Sent from my iPhone
On Dec 12, 2008, at 7:02 AM, Brett Porter <br...@apache.org> 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.
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 would suggest treating the über JAR like an assembly where you have
a separate project.
- unpack the final JAR into the classesDirectory (the original patch)
- replace the outputDirectory with the JAR (cleaner and more
concise, but effectively makes the output directory read-only from
the package phase, might have unexpected side effects if someone
modifies the output afterwards, though that would seem unwise anyway)
- don't fix it, require people to use <shadedArtifactAttached>true</
shadedArtifactAttached> instead and depend on the one with the
classifier.
Opinions?
Cheers,
Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
