[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950845#comment-15950845
 ] 

Joseph Witt commented on NIFI-3628:
---

[~ottobackwards] Rgr that.  Thanks.  I do agree not having tests in the nar 
plugin at this point is a detriment to reliably tweaking it.  The change was 
small admittedly but it made something all about 'nar' able to be about some 
other set of letters and it is in a really commonly/stable used bit of code so 
it just alters the scary factor a bit.  Will be cool to see if these end up 
converging together.  We haven't really had the expertise on the maven plugin 
development or testing side to take it very far i think

> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Tools and Build
>Affects Versions: nifi-nar-maven-plugin-1.2.1
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950819#comment-15950819
 ] 

Otto Fowler commented on NIFI-3628:
---

I will close this, I am adapting the plugin in metron.  We'll come back to it 
if warranted.


> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Tools and Build
>Affects Versions: nifi-nar-maven-plugin-1.2.1
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950814#comment-15950814
 ] 

ASF GitHub Bot commented on NIFI-3628:
--

Github user ottobackwards closed the pull request at:

https://github.com/apache/nifi-maven/pull/2


> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Tools and Build
>Affects Versions: nifi-nar-maven-plugin-1.2.1
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936786#comment-15936786
 ] 

Otto Fowler commented on NIFI-3628:
---

I agree with what you have laid out here, in fact that is what I am doing with 
nifi-nar-utils.  I think this is correct because the refactoring I'm doing will 
most likely not be taken into nifi either.  My thought there is that if we want 
to reconcile the metron work with the nifi base, a third new thing will be done 
that bring the efforts together.

Because the changes are straight forward, and do not put necessitate any nifi 
project changes to adapt, I thought I would give the PR a shot.  I am adapting 
this code into metron however, with the idea that maybe this does land and we 
can just switch over.

Given how little this code changes ( by it's own description ) I'm not sure how 
much of a maintenance burden this would be, but I would not argue with your 
point.

Not having a test suite for the plugin makes this matter more difficult.


I am already doing as you suggest.
Should I close this then?  and the PR?
 

> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Tools and Build
>Affects Versions: nifi-nar-maven-plugin-1.2.1
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936729#comment-15936729
 ] 

Joseph Witt commented on NIFI-3628:
---

[~ottobackwards] In reviewing this proposed change and patch there are two 
concerns that come to mind.

- It changes the 'NiFi Nar Maven Plugin' to support being called something 
other than a "nar" but instead a definable type.  This could lead to confusion 
where this nar plugin is able to be called/considered as something other than a 
nar.

- It is a change which makes the plugin more generalizable which is useful but 
adds to the maintenance burden of the nifi project/pmc without really 
benefitting the nifi project.  By no means am I saying that means this should 
not be done but rather i'm implying we're probably better off considering if 
there should be a more generic concept/project for this that can be used by 
multiple projects.  Perhaps just two projects wanting this right now is not 
enough to warrant that.  With this in mind I'd advocate that our nar plugin 
source just get copied/forked into metron's codebase and you can adapt it as 
needed.  If there is a decision to make a separate project for this we could 
help that.  If we do something like that then it makes sense it would be called 
something like 'dependency-archive' or 'dependency-bundle' or something.  Not 
sure of the naming but the concept, design/implications, of the nar are pretty 
well tied into NiFi's design.


> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3628) Allow configuration of nifi-nar-maven-plugin to control output and manifest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933202#comment-15933202
 ] 

ASF GitHub Bot commented on NIFI-3628:
--

GitHub user ottobackwards opened a pull request:

https://github.com/apache/nifi-maven/pull/2

NIFI-3628  allow override additions for extention and id prefixes

This PR introduces the ability to change the extension name though changing 
the type property as well as specifying the prefix on the Nar- manifest 
entries.

The type property is used to specify the file extension, and hardcoded 
instances of 'nar' are changed to use this property consistantly.

The property is also used in the NarDependencyMojo, such that the hardcoded 
NAR='nar' usage is changed to use the type property.   The configuration of 
this property will govern both mojos.

The defaults are all left as [N,n]ar.  Such that there are NO required 
changes to existing POMs or archetypes to continue working after this change.

This was tested by building building the archetype, and building nifi with 
the pom reference changed to the version built ( validating from the logs the 
plugin version used ).

All tests run and pass

Nifi was run from the assembly dir, and a flow created, logs viewed to 
verify that there were no errors loading / unpacking the nars, running the 
flows.




You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ottobackwards/nifi-maven NIFI-3628

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-maven/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit f876fb78d90a3a93363c4d9473ad4315eca0b58a
Author: Otto Fowler 
Date:   2017-03-20T14:00:35Z

override additions for extention and id prefixes
override prefix for Nar-* manifest properties




> Allow configuration of nifi-nar-maven-plugin to control output and manifest
> ---
>
> Key: NIFI-3628
> URL: https://issues.apache.org/jira/browse/NIFI-3628
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Otto Fowler
>
> The nifi-nar-maven-plugin produces .nar files, and also looks for 'special' 
> nar dependencies with .nar extensions. 
> It also inserts manifest entries with special nifi properties used by the 
> nifi runtime system ( nifi-nar-utils ).
> The changes proposed here would allow for other projects to use nar formatted 
> archives while specializing them to fit that project.
> Specifically - 
> Allowing the configuration of the prefix used when writing out the nar 
> specific manifest entries ( Nar-Group etc ), such that another project could 
> change those properters to be Other-Group etc.
> Utilizing the 'type' property to control the output file extension name, and 
> removing hard coded 'nar' strings.
> This should be done in both the NarMojo and the NarDependencyMojo.
> The NarDependencyMojo should be modified to honor the type parameter setting, 
> instead of a hard coded value as well.
> These changes should be made such as with default settings no modifications 
> to existing NiFi bundles will be required
> With these changes, other projects, such as Apache Metron (incubating) will 
> have the ability to use and adapt the nar artifacts without forking or 
> creating duplicate functionality in the long run.
> A sample configuration would be :
> 
>   
> org.apache.nifi
> nifi-nar-maven-plugin
> 1.2.1-SNAPSHOT
> 
>   Par
>   1.0
>   foo
>   foobars
>   par
>   pom
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)