Re: Should I withdraw this PR?

[Joe Witt]

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 example.  If you do this you
also dont need any of the licensing/notice impacts to show up in the
nifi-assembly/L

2) Don't merge at all.  Keep this outside of the project in its own
github repo.  Provide instructions on how to build, include in nifi,
and make a great blog on how it can be used to test nifi record
oriented flows/configurations/etc.  Going this route means it is
outside the community but still useful and helpful to the community.

I haven't looked into it in detail to know how big it is nor how
configurable/capable it is for generating useful sample data for
exercising record processors and configurations.  So, i dont have a
strong preference/understanding relative to which of the above options
is best.  I'd defer to you or folks that reviewed more closely.

Thanks
On Wed, Aug 29, 2018 at 3:55 PM Mike Thomsen  wrote:
>
> https://github.com/apache/nifi/pull/2813
>
> I have been building a bundle that complements it. Repo is here:
>
> https://github.com/MikeThomsen/nifi-datageneration-bundle/
>
> Joe raised a valid point in the PR about us being space-constrained in the
> assembly, and so I'm wondering if I should just move it over to that repo
> and point the Jira ticket to it.
>
> Thoughts?

Re: Licenses for test dependencies

[Joe Witt]

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

On Thu, Aug 30, 2018 at 4:25 PM James Srinivasan
 wrote:
>
> 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 thanks,
>
> James

Licenses for test dependencies

[James Srinivasan]

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 thanks,

James

Re: Comparing NiFi API versions between releases

[Kevin Doran]

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 will never be
deletions or breaking-changes.

## For the REST API

For the last several versions of NiFi, a Swagger/OpenAPI [2][3]
specification (swagger.json file) is generated from the source code build,
here:


/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/target/swagger-ui/swagger.json

For previous releases, you can either build from source by checking out the
tag associated with the release version (rel/nifi-).
I'm not sure if the ordering of this JSON file is deterministic, but
diff'ing it across versions might be one way to pinpoint changes.

## For the Java APIs

I don't know of a quick trick for this, but you can narrow the problem down
a lot if you are only concerned about external-facing NiFi APIs for
extension points, most (all?) of which are in modules that end in "-api":

find /path/to/nifi-source -type d -name "*-api" -print

Hope this helps,
Kevin

[1] https://semver.org
[2] https://swagger.io
[3] https://github.com/OAI/OpenAPI-Specification



On Thu, Aug 30, 2018 at 3:17 PM Jagrut Sharma 
wrote:

> 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
>

Re: Comparing NiFi API versions between releases

[Andy LoPresto]

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] https://lvc.github.io/pkgdiff/ 
[2] https://github.com/scala/jardiff 

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Aug 30, 2018, at 12:17 PM, Jagrut Sharma  wrote:
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Comparing NiFi API versions between releases

[Jagrut Sharma]

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