Matt, I am supportive of this especially given the nice boost it provides for people wanting to understand the structure/dependencies of a given Nar.
Also 3.0.5 is from early 2013 and 3.1.0 is from later 2013 so we're still going a long ways back [1]. Thanks Joe [1] https://maven.apache.org/docs/history.html On Mon, Aug 17, 2015 at 8:12 AM, Matt Gilman <[email protected]> wrote: > 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 >>
