nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Gilman <matt.c.gil...@gmail.com>
Subject Re: Update to nifi-nar-maven-plugin
Date Mon, 17 Aug 2015 12:12:06 GMT
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 <matt.c.gilman@gmail.com>
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message