Hi again, >> could split my project and have 2 modules, one simply being the >> standalone/shaded version of the other, but it seems overkill, since >> they're really the same source.
On 27 October 2010 19:33, Wayne Fay <[email protected]> wrote: > This is the correct approach (imo). Two artifacts, one for the > provided artifact, another for the shaded artifact. On 27 October 2010 19:49, Antonio Petrelli <[email protected]> wrote: > The multi-module path is the best. Why do you say that they share "the > same source"? The shaded project must have a dependency on the > original project, so it takes the compiled version, not the source. This actually does not really solve my problem. Parent: !-- projectA - the "regular" project, which depends on thirdParty with scope:provided !-- projectB - the new "shading" project, which depends on projectA The only way I can get projectB's generated shaded jar to also include thirdParty is to redefine that dependency in projectB and change its scope. Which would be ok if projectA had that single dependency. Unfortunately it has a few more. On of the reasons my dependencies are in scope:provided, is because we also build an assembly with the regular jar and a few text files. Dependencies don't need to be shipped with this; we use a common assembly descriptor where dependencies in scope:provided are excluded. I just tried the same approach for this assembly, i.e extract it to a 3rd module, but I still run in the same issues. It looks like I'll either have to add a bunch of <exclude> in my assembly's dependency to projectA .. or re-declare all deps of projectA in projectB. Neither is appealing nor convenient... any other option ? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
