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/08/17 14:12:06 UTC
Re: Update to nifi-nar-maven-plugin
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>.
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
>>