[
http://jira.codehaus.org/browse/MSHADE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MSHADE-42:
-------------------------------
Attachment: MSHADE-42-alternate.diff
an alternate patch.
This is cleaner and cheaper, but may have side effects if subsequent plugins
expected a directory. I'm not that comfortable applying it, so I'll go with the
first one.
I think this is considered a bug in Maven itself - if the JAR was produced, it
should be used instead. The artifact is the output, the target/classes is just
an optimisation for running earlier lifecycle phases.
> Reactor builds do not use shaded jar
> ------------------------------------
>
> Key: MSHADE-42
> URL: http://jira.codehaus.org/browse/MSHADE-42
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Dave Meibusch
> Attachments: MSHADE-42-alternate.diff, MSHADE-42.patch
>
>
> I have a multi-module project with several of the modules using shade to
> create uber jars.
> One the modules depends on an uber jar module. When doing a reactor build,
> this module is built with a compile classpath containing:
> /xxx/yyy/uberjar-module/target/classes
> rather than the shaded uber jar created (and installed) earlier in the
> reactor build.
> When the module is built alone, the dependency in the compile classpath is
> correctly the shaded jar in the local repository.
> I don't know enough about the internals of reactor builds to determine if
> this is a deficiency of the shade plugin or Maven's reactor mechanism.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
