nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff <jtsw...@gmail.com>
Subject Re: [DISCUSS] Assembly size for 1.10
Date Thu, 22 Aug 2019 01:59:19 GMT
How motivated could we be to do the reorganization of the NiFi repository
before the 1.10.0 release?  It sounds like we have a few paths to get the
resulting convenience binary down below the size limit.  If we don't do the
reorganization for this upcoming release, we should make it a top priority
for the following release.

On Wed, Aug 21, 2019 at 6:22 PM Mike Thomsen <mikerthomsen@gmail.com> wrote:

> Another factor on why that would be a good idea: I might soon have to pivot
> and do the R&D on adding dgraph support to graph bundle. So it's not
> altogether unlikely that it might need to be refactored to make room for
> other graph tech.
>
> On Wed, Aug 21, 2019 at 6:20 PM Mike Thomsen <mikerthomsen@gmail.com>
> wrote:
>
> > 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 <joe.witt@gmail.com> 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 <bbende@gmail.com> 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 <aldrin@apache.org>
> 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
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message