On 1 October 2013 02:49, Bear Giles <bgi...@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 >
