maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: maven shade: how to actually use custom shader (plus a few ideas)
Date Tue, 01 Oct 2013 08:02:43 GMT
On 1 October 2013 02:49, Bear Giles <> wrote:

> First the question: how do I actually use a custom shader? I've created my
> own Shader implementation based on DefaultShader, set a new hint, and
> modified the working pom.xml entry with
> <shaderHint>myShaderHint</shaderHint>.
> It blows up - it can't find a class implementing the Shader interface. I
> KNOW that that class is present, I don't know why it can't find it. I also
> tried adding <shader implementation="fully.qualified.class.Name"/>. No joy
> there either.
> So how do I specify the custom shader???

Are you adding the dependency with the custom shader as a *dependency of
the plugin*?


in xpath you'd be creating a code


and that node would specify the artifact that has your custom shader

> Now two ideas. I would contribute code but my employer is rather paranoid
> so my hands are tied until the end of my contract. Fortunately these are
> simple ideas that would only take a few hours for someone familiar with the
> code to knock out.
> 1. Add "artifact" to ShadeRequest. This lets the custom shader to make a
> distinction between "internal" dependencies and "external" dependencies.

Not sure I'm getting the need for this... to be honest it smells like
you've gone down a rabbit hole with one way of thinking and you might be
better served taking a different tack... but please explain your thinking.

> 2. Add a standard Shader that creates a jar-of-jars instead of an uberjar.
> The specific motivation for the jar-of-jars is that we need to collect
> dependencies for third-party vulnerability assessment. We've been doing it
> by hand but it's very error prone. With a trivial change to DefaultShader
> we can immediately create a jar containing all of the dependencies. We can
> then upload that monster for assessment.
> (The ability to capture the corresponding source is a free additional
> benefit!)

I think the assembly plugin can do exactly this for you.

> 3. We're trying to implement a refinement of the second item. The specs are
> still in flux but the idea is that anything "internal" (same groupId) goes
> in the parent directory but is stripped of version information. Everything
> else goes into a "lib" directory. Again the idea is that it makes it much
> easier to pass to a third-party validation tool. I don't know if this is
> too specific for a general tool or if it's something easily supported with
> a configuration flag or two.

Again this is easy to do with the assembly plugin as I understand it.

> Thanks,

We'd like to keep plugins close to single principle as we can, so
replicating a load of features from the assembly plugin into the shade
plugin feels like an anti-pattern to me. From my point of view shade should
be for shading.

> Bear

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message