maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bear Giles <bgi...@coyotesong.com>
Subject Re: maven shade: how to actually use custom shader (plus a few ideas)
Date Tue, 01 Oct 2013 20:14:44 GMT
Knowing that something can be done and should be easy is half the battle! I
have no idea why the people in charge of deployments had problems figuring
out how to do this - it only took me a few hours to get everything nailed
down.

Bear


On Tue, Oct 1, 2013 at 7:04 AM, Bear Giles <bgiles@coyotesong.com> wrote:

> >> 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.
>
> I'll pass that back up the food chain. I'm sure we've discussed using
> assembly but it was rejected. It wouldn't surprise me if one person
> specified dependencies by hand and everyone's just followed what worked.
>
> Bear
>
>
> On Tue, Oct 1, 2013 at 2:02 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> On 1 October 2013 02:49, Bear Giles <bgiles@coyotesong.com> 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*?
>>
>> i.e.
>>
>> in xpath you'd be creating a code
>>
>> /project/build/plugins/plugin/dependencies/dependency
>>
>> and that node would specify the artifact that has your custom shader
>> implementation
>>
>>
>> >
>> > 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
>> >
>>
>
>

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