> I understand that convenience binaries might some issues with uberjars
when
we go that route for 1.0. But is there any issue with the uberjars as
things currently stand? I was under the impression we are OK because we
don't distribute them.
My impression is that this incorrect and it was the
So, since NiFi does produce binaries, they require NOTICE and LICENSE
updates in two places:
- the ‘package’ itself. With nifi usually this is the .nar file ( nars are
just jars ).
- the nifi-assembly module which builds the .zip binary distribution.
It is normal and expected during reviews
There is a distinction. The dependencies_with_url.csv does manage to make
sure our dependencies (and transitive dependencies) are appropriately
accounted for. What we also need to do is make that any changes (if
necessary) to the LICENSE and NOTICE files also make it in there. For
example,
Woop woop!
On Wed, Sep 12, 2018 at 12:15 PM Justin Leet wrote:
> The vote has passed. Including my +1, the voting was:
> 3 binding +1’s
> 1 non-binding +1’s
> no 0’s
> no -1’s.
>
I'm not sure I fully understand what is out of date. I know I have
personally modified our licenses a couple times in the past and used an
automated script that, I believe, Casey Stella had created for doing the
check. I even made some improvements to it a long ways back. It rips
through the maven
Hi all,
As mentioned on the release voting thread, there was a Slack discussion
around our LICENSE and NOTICE file likely being outdated because they
haven't been actively kept up to date since graduation. I suggested on the
vote thread that we proceed with the current release, but consider it a
The vote has passed. Including my +1, the voting was:
3 binding +1’s
1 non-binding +1’s
no 0’s
no -1’s.
Hi all,
There was a discussion on Slack that I wanted to bring back to the list
regarding our LICENSE and NOTICE files.
These files appear to be stale since our graduation to TLP, however they
likely should have been updated throughout their lifetime. I'll be
starting a discuss thread shortly
Totally agree with replacing dot with something else. We have had so much
drama to use either dot or column with ORC either via Hive or Spark.
Although we have replaced it with an underscore, it may not be a good idea
as it can be confusing with underscores in the internal field names.
Cheers,