Awhile back I proposed a new maven plugin that would allow a processor developer to easily see the provided dependencies their NAR would be inheriting. This can become unclear if the processors depend on a Controller Service API NAR (either directly or transitively through another Controller Service API). After sending this email awhile ago, nobody seemed opposed to moving to a minimum maven version of >= 3.1.0. I would like to move forward with including NIFI-376 in our 0.3.0 release.
See the original message below for all the details. Any objections? Matt [1] https://issues.apache.org/jira/browse/NIFI-376 On Tue, Mar 17, 2015 at 3:47 PM, Matt Gilman <[email protected]> wrote: > I am in the process of adding some functionality to the > nifi-nar-maven-plugin. I'm hoping that someone has some guidance or more > knowledge of Maven than I do. > > Background - > NiFi provides classpath isolation using NARs [1]. A NAR can have a parent > NAR. This is typically used to reference controller service definitions. > For instance, if your processor needs to use the SSLContextService. The > parent NAR maps directly to the parent classloader of the NAR in question. > > Known Issue - > When developing a NAR that has a NAR dependency, you will need to know the > transitive dependencies that will be automatically added the NARs classpath > at runtime. By definition, NARs 'include dependencies' (like a WAR file). > This means that traditional maven dependency tree listings do not show the > transitive dependencies in question. Determining the provided dependencies > becomes very difficult even for those most familiar. The update to the > nifi-nar-maven-plugin prints this dependency hierarchy. > > Concession - > The proposed solution is not 100% accurate as the framework dynamically > injects some JEE/Jetty dependencies automatically to support loading custom > UIs from any NAR. Additionally items in the lib directory are also > automatically included in every classpath. I realize these are important > but they cannot be resolved using Maven at build time due to the dynamic > nature of the classpath at runtime (putting a jar in the lib directory). > However, the plugin still has merit in helping developers understand what > the implications are when depending on a NAR. > > Reason for this Email - > I've created the plugin [2]. However, the component that performs the > artifact resolution has moved from org.sonatype to org.eclipse as of Maven > 3.1. I'm not sure how I would go about supporting both at the same time. > Others have also had this issue [3] but I've not seen a solution that > addresses the concern directly. > > Ultimate Question - > 1) Should we be concerned with supporting Maven 3.0? The current minimum > version needed for NiFi is 3.0.5 according to the Quickstart guide [4]. > 2) If we want to support Maven 3.0, is there are solution that can support > both Maven 3.0 and 3.1 concurrently? Is there something that I overlooked > or missed entirely? > > I'm hoping to avoid having to release multiple versions of the plugin. > > [1] > https://nifi.incubator.apache.org/docs/nifi-docs/developer-guide.html#nars > [2] > https://github.com/apache/incubator-nifi/blob/NIFI-376/nifi-nar-maven-plugin/src/main/java/org/apache/nifi/NarProvidedDependenciesMojo.java > [3] > http://stackoverflow.com/questions/17685441/can-a-maven-mojo-relying-on-aether-be-compatible-with-maven-3-0-x-and-3-1-x > [4] https://nifi.incubator.apache.org/development/quickstart.html >
