Hi Nick!
In chatting with Sean before sending this email, he pretty much
suggested the same thing to me. I think this is the eventuality I need
to embrace -- was just hoping for something a little less drastic for a
first contribution ;)
Thanks for your time in sending this!
On 8/3/18 12:47 PM, Nick Dimiduk wrote:
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
