maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: maven shade: how to actually use custom shader (plus a few ideas)
Date Tue, 01 Oct 2013 22:44:57 GMT
Glad to have been of help!


On 1 October 2013 21:14, Bear Giles <bgiles@coyotesong.com> wrote:

> 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