[
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
<tl;dr>
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 :
> <plugins>
> <plugin>
> <groupId>org.apache.nifi</groupId>
> <artifactId>nifi-nar-maven-plugin</artifactId>
> <version>1.2.1-SNAPSHOT</version>
> <configuration>
> <packageIDPrefix>Par</packageIDPrefix>
> <narDependencyVersion>1.0</narDependencyVersion>
> <narDependencyId>foo</narDependencyId>
> <narDependencyGroup>foobars</narDependencyGroup>
> <type>par</type>
> <mode>pom</mode>
> </configuration>
> </plugin>
> </plugins>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
