Building the shaded module separately was my workaround for a few days. My current workaround is to specify the intra-module dependency in my parent pom under dependencyManagement with a list of exclusions for the artifacts I am shading into it. Effectively I am manually "reducing" the dependency set of the shaded module as seen from within the multi-module project.
However, I think it might be best for Maven to (re-)allow the set of dependencies listed to reduce after build due to plugins like maven-shade-plugin. While needing to shade in general is not ideal, needing to build the module outside of the reactor in addition to shading is less ideal, especially in a larger project where it may need to be ordered between other modules to successfully build. See: https://issues.apache.org/jira/browse/MSHADE-206 See: https://issues.apache.org/jira/browse/MNG-5899 On 3/18/19 5:12 PM, Francois MAROT wrote: > Hi Nikki, > > Regarding your question, I'm not sure of what is a "reactor of reactor"... > by 2 separate "projects" I mean 2 different build. Hence 2 different > "reactor". > As I understand it, the reactor is the sum of all Maven modules > participating in the build. Usually in the case of a multi-modules Maven > project, you start the build from the top level module, and all your modules > are part of the same rector. Part of the same build. > I personally like to have one git repository per multi-module Maven project > so we have: > > 1 git repo --> containing one multi-modules Maven project ⊃ composed of many > modules == one build == one reactor > > What is sure is that for the shade plugin to work, you have to make Maven > builds depending on the shaded artifact find this artifact stored in a repo > (whether local or remote) and not reference it as a module inside the > reactor (ie part of the same build). > > I hope it helps !
signature.asc
Description: OpenPGP digital signature
