Hi Josh, My comment here is not specific to Yetus. I've had problems in the past with a multi-module project where (1) one of the modules, call it module A, produces a shaded artifact A' and (2) another module, say module B, depends on that shaded artifact. There's a "feature" of Maven (sorry, couldn't locate the issue this morning) where the the dependency of A provided to B is not the shaded A' artifact, but rather the unshaded A artifact with its full transitive dependency stack. The only solution I've found to the problem is to move construction of the shaded A' artifact to an entirely different Maven project and have module B consume it as any other 3rd party dependency. Until I realized this issue, I suffered from many unexplainable ghosts of dependency resolution in my projects.
Hope this helps. -n On Thu, Aug 2, 2018 at 10:58 AM, Josh Elser <[email protected]> wrote: > Hi, > > I'm trying to fix some Maven-weirdness in Ratis, and as a result have > found that Precommit is a broken from my "fixing" :). This is a little > complicated, so let me try to explain what's happening at a high level: > > Ratis has a Maven module in which they compile from protobuf definitions > and then bundle relocated, third-party dependencies into a jar for the rest > of the Maven modules to use. They presently do this in four steps: > > * Generate protobuf java source > * Use shade-plugin to create a source jar for the third party deps with > relocation. > * Unpack that shaded source-jar > * Recompile all of the code to create a single jar > > This can obviously be simplified into the following, skipping that > unpacking step (halving the build time of that module): > > * Compile protobufs and build jar > * Use shade-plugin to include relocated, third-party code into a jar > > The fun part is that this change breaks Precommit because the maven plugin > is using the "test-compile" Maven lifecycle phase for the "unit", > "findbugs", and "compile" Yetus tests. It breaks precommit because the > shade-plugin doesn't run until the package lifecycle phase, and thus > downstream Maven modules from this one miss all of the third-party code > because the shaded jar wasn't built (the Maven reactor only finds the > compiled protobuf classes). > > I think the long term solution is to pull out the shading of third-party > deps into its own jar and pull it out of the Ratis day-to-day build. > > I am hoping to come up with a workaround for now. I could change the > shade-plugin to bind to the compilation phase instead of package but that > goes against the "maven way". I was hoping to find any way that would let > me override `maven_modules_worker`, shy of copying/modifying the entire > plugin. Any suggestions? > > Thanks in advance! > > - Josh >
