You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Matt Gilman <ma...@gmail.com> on 2015/03/17 20:47:23 UTC
Update to nifi-nar-maven-plugin
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.
Other 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
Re: Update to nifi-nar-maven-plugin
Posted by Matt Gilman <ma...@gmail.com>.
Thanks! I will be introducing the new plugin [1] for 0.3.0 and will be
updating all corresponding documentation regarding the minimum Maven
version.
Matt
[1] https://issues.apache.org/jira/browse/NIFI-376
On Mon, Aug 17, 2015 at 8:59 AM, Joe Witt <jo...@gmail.com> wrote:
> 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 <ma...@gmail.com>
> 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 <ma...@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
> >>
>
Re: Update to nifi-nar-maven-plugin
Posted by Joe Witt <jo...@gmail.com>.
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 <ma...@gmail.com> 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 <ma...@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
>>
Re: Update to nifi-nar-maven-plugin
Posted by Matt Gilman <ma...@gmail.com>.
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 <ma...@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
>