jrh3k5 / flume-plugin-maven-plugin Goto Github PK

When doing a mvn release:prepare on a reactor project that contains a project and a subsequent project that creates a Flume plugin tarball and depends on the first project for its tarball, you'll get an error because the Flume plugin tries to copy the first project's JAR from the local Maven repository - where it doesn't exist.

The plugin should bundle the project and its dependencies - compile and runtime - into a .tar.gz archive that matches the expected structure of a Flume plugin.

Some consumers of Flume use the Cloudera distribution, which uses a ".parcel" format (which is a .tar.gz with some meta descriptor files) to distribute things like plugins.

Some doc can be found here:

http://blog.cloudera.com/blog/2013/07/one-engineers-experience-with-parcel/

To reduce the size of Flume plugins and to avoid classpath collision of Flume plugins, Flume plugins should be assembled with the Flume agent dependencies excluded.

Currently, we can exclude an artifact from being included into an assembly by group ID and artifact ID; however, in a specific scenario, the maven-clover2-plugin generates an artifact for the project with a '-clover` classifier that gets pulled into the bundled assembly because it's attached to the project. We don't want to ship Clover-instrumented JARs as part of our Flume plugins, so it'd be nice if the ability to exclude based on classifier was added to the plugin.

The plugin should, given a dependency, bundle it as the primary library and its dependencies - runtime and compile - in a .tar.gz in a format that matches the Flume plugin structure.