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 <[email protected]> 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 < > [email protected]> wrote: > >> On 1 October 2013 02:49, Bear Giles <[email protected]> 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 >> > >> > >
