Go ahead and remove the whole graph bundle from the assembly. I would recommend cutting a release of it separately and putting it up on GitHub's releases listing if that's a possibility for us/INFRA w/ GitHub. Most of our potential graph users are savvy enough that if add a few steps, I don't see it causing any grief on them getting it stood up and giving us feedback.
Might be a good idea also to add a "full-build" profile to the assembly so that we can throw the whole kitchen sink into an unofficial build if we build it ourselves for someone else. On Wed, Aug 21, 2019 at 3:09 PM Joe Witt <[email protected]> wrote: > Bryan > > I agree with all of that. What does that get us to? > > Thanks > > On Wed, Aug 21, 2019 at 3:03 PM Bryan Bende <[email protected]> wrote: > > > I would vote to make nifi-flume-nar optional, and it looks like > > nifi-other-graph-services-nar might be new since last release, so > > since that is in the top 10 and not released yet, it might also be a > > good candidate (not downplaying the usefulness of anything in that > > NAR). > > > > I would also think we could consider the nifi-kafka-0-8-nar since > > Kafka 0.8 is quite old at this point, and we already have other Kafka > > NARs for 0.9, 0.10, 0.11, 1.0, and 2.0. Might even consider dropping a > > few more versions from default assembly. > > > > On Wed, Aug 21, 2019 at 2:45 PM Aldrin Piri <[email protected]> wrote: > > > > > > Hi folks, > > > > > > Doing a recent PR review and build, it seems that master has amassed > some > > > additional size since our 1.9.2 release approaching 200MB. > > > > > > Unfortunately, this is problematic and needs to be addressed in advance > > of > > > our 1.10 release. INFRA has been more than helpful making one off > > > exceptions [1][2] for the larger assembly to get published to the ASF > > > repository and its associated mirrors, but another release that is even > > > larger is not something we can allow. In a Linux environment, the > master > > > build reports in at 1575671276 which puts us over the hard limit > > > highlighted in [2]. > > > > > > We had a prior community discussion [3] about splitting the framework > and > > > extension repos and I am hoping to revive that discussion, in part. We > > > certainly know what our longer term goals and ambitions are but need a > > fix > > > in the interim. In the current state, we will not be able to make our > > > convenience binaries available at the conclusion of the release > process. > > > > > > At minimum we should evaluate which bundles are eligible to get treated > > as > > > optional dependencies and only enabled via profile, much like the work > > that > > > has occurred surrounding some of our other, hefty NARs. [4] A listing > of > > > the top 50 largest NARs, excluding framework and standard, is available > > in > > > a gist [5]. The nifi-media-nar looks to be a good initial candidate > for > > > exclusion. > > > > > > Thanks for your consideration! > > > > > > --aldrin > > > > > > [1] https://issues.apache.org/jira/browse/INFRA-11252 > > > [2] https://issues.apache.org/jira/browse/INFRA-15816 > > > [3] > > > > > > https://lists.apache.org/thread.html/939a7630a2e32594cd10444e48b7a1321fd9ce51834d911a8c04b6a9@ > > <dev.nifi.apache.org> > > > [4] > > > > > > https://github.com/apache/nifi/blob/master/nifi-assembly/pom.xml#L807-L875 > > > [5] https://gist.github.com/apiri/4d9a02f9f6b46867b601956df83b6d8c > > >
