Mike
I'd say there are a couple of options.
1) Don't add the nar to the nifi-assembly. Leave the source in there.
It still gets built. Just dont bundle the nar in the resulting build
by default. You could have a profile based activation to include it
like is done for hive3 i believe - for
James,
I don't believe you need to do anything with these in terms of
updating files to reference their license unless the changes you make
result in their code and or other artifacts such as jars to end up in
our resulting source distribution or our convenience binary
distribution.
Thanks
Joe
I am not a lawyer (and you probably aren't too), but what should I do
to document the licenses of dependent libraries of the processor I
want to contribute that are only used with a Maven 'test' scope i.e.
not bundled in the nar?
Also, same question for plugins that run in the test scope.
Many
Hi Jagrut,
Are you referring to the REST API or the public Java interfaces and classes?
As a general note, NiFi versions follow semantic versioning [1] guidelines,
so for external-facing APIs (both Java and REST), there may be additions or
non-breaking changes across minor versions, but there
Hi Jagrut,
You can perform a diff on the nifi-framework-api bundle using pkgdiff [1] or
jardiff [2], which should give you the information you’re looking for. There
shouldn’t be many changes to the API in minor releases. Those changes are
generally held for major releases.
[1]
Hi - Is there an efficient way to compare NiFi APIs between releases 1.6.0
and 1.7.1 to identify changes, additions, deletions etc.
Thanks!
--
Jagrut
