[
https://issues.apache.org/jira/browse/NIFI-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 :
> <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)
