Mike
Yep - that will need to get addressed/improved as well. First step is
get the root classpath cleaned up again (NIFI-2971) and the next step
is to understand and address the excessive declaration of dependencies
which leads to duplication on such a scale.
Thanks
Joe
On Tue, Nov 1, 2016 at
I would like to point out that some very common dependencies have been
placed into the nifi-standard-services-api-nar. This nar is a
Nar-Dependency-Id of several other nars. Many of these other nars also
include the same dependencies, which would not be used by the nar class
loader.
In
I think in light of the fact that the bcprov item was an accidental
inclusion and not explicitly meant to be handled as such in the framework
reorganizing seems like the best option as well. The original intent of
the PR was to minimize that footprint where we were double dipping given
the
So...I might be a bit of a flip flopper...
Had some off-list discussions with a couple people and they really
disliked this idea. They, rightfully, pointed out how this
establishes a problematic precedent, how it is really only being done
to save space, and that while perhaps not able to pair
+1 as well.
On Tue, Nov 1, 2016 at 2:41 AM, Joe Witt wrote:
> Team,
>
> In the 1.x line bcprov made its way into the root of the classpath/lib
> folder to support the encrypted sensitive properties features. This
> can be reworked to isolate it a bit more if we need to.
>
>
Team,
In the 1.x line bcprov made its way into the root of the classpath/lib
folder to support the encrypted sensitive properties features. This
can be reworked to isolate it a bit more if we need to.
However, in [1] it has been observed that we have bcprov dependencies
in about 53 places with