Glad to have been of help!
On 1 October 2013 21:14, Bear Giles <[email protected]> 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 <[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 > >> > > >> > > > > >
