> On 18 Jan 2018, at 03:05, Matt Burgess <mattyb...@apache.org> wrote: > > - Some NiFi installs will be located on systems that cannot contact an > outside (or any external) repository. When we consider NAR > repositories, we should consider providing a repo-to-go or something > of that sort. At the very least I would think the Extension Registry > itself would support such a thing; the ability to have an Extension > Registry anywhere, not just attached to Bintray or Apache repo HTTP > pages, etc.
I would imagine that most NiFi installs would not be able to contact the outside due to many running on edge nodes of clusters with strict routing rules. > Optimized JARs/classloading > > - Promoting JARs to the lib/ folder because they are common to many > processors is not the right solution IMO. With parent-first > classloaders (which is what NarClassLoaders are), if you had a NAR > that needed a different version of a library, then it would find the > parent version first and would likely cause issues. We could make the > NarClassLoader self-first (which we might want to do under other > circumstances anyway), but then care would need to be taken to ensure > that shared/API dependencies are indeed "provided". This is what I was getting at with my earlier question regarding explicitly exporting packages and specifying nifi based versioning. This is the way IDE’s tackle the problem, if I wanted to expose a given jar dependency in NetBeans for example I would create a wrapper nbm for 1 or more jars and explicitly expose a list of packages.
