Hello! Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1*
I have prepared assemblies for Apache Ignite slim packaging: https://github.com/apache/ignite/tree/ignite-slim It is based on ignite-2.8 You can build it with mvn initialize -Prelease,lgpl -Dignite.edition=apache- ignite-slim after a normal release build. Please consider the contents of resulting target/bin/apache-ignite-slim-2.8.0-bin.zip It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 distribution. My suggestion is that we can publish it as a post-release step since it does not affect the release in any way. If we do, we should probably indicate size for every kind of artifact in our download section, so our users can choose based on that information. The following modules are included: libs: core/shmem/jcache ignite-indexing ignite-spring libs/optional: ignite-compress ignite-kubernetes ignite-log4j2 ignite-rest-http ignite-spring-data_2.2 ignite-jta ignite-log4j ignite-opencensus ignite-slf4j ignite-urideploy I have kept examples, but removed benchmarks. sqlline still present, of course. ignite-zookeeper has a lot of dependencies (8M) which we do not update often enough (such as guava, curator, jackson), and which may form an attack surface. Not a pressing problem for 'integrated' ignite-zookeeper users, since they can re-import these dependencies with more recent versions using maven or gradle. But for our users who rely on binary package for all JARs, outdated dependencies may pose a problem. Therefore my opinion is to exclude this dependency and not put our faith on zookeeper dependency version. The same can be put for ignite-compress, and indeed, I'm not sure if we should keep it. We can have an ad-hoc vote here. I would like to hear arguments for both inclusion and exclusion of ignite-zookeeper and ignite-compress into slim package (in any combination). I would also like to know if you want a formal vote on the issue. Regards, -- Ilya Kasnacheev пн, 27 янв. 2020 г. в 21:13, Denis Magda <dma...@apache.org>: > Alex, could you please list all the modules that will be excluded? It will > help to confirm we haven't dumped anything essential. > > - > Denis > > > On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > Got it, sounds good! > > Should we consider the list of modules included in the slim package > > finalized? > > > > чт, 16 янв. 2020 г. в 13:13, Igor Sapego <isap...@apache.org>: > > > > > Alexey, if I understand correctly, Ilya does not suggest to pre-built > > > binaries, just to ship it with configure script pre-generated, which > > > is a common practice for autotools packages. Building will be still > > > required for the user, but there will be less requirements and > > > possible errors during build. > > > > > > I like the idea. Let's do this. > > > > > > Best Regards, > > > Igor > > > > > > > > > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < > > > alexey.goncha...@gmail.com> wrote: > > > > > > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I > > would > > > > not name it 'core' because indeed it would be confusing with the core > > > > module name. > > > > > > > > Agree that platforms support is useful, so I would keep them as Ilya > > > > suggested. As for the C++ packages pre-build - let's hear out Igor's > > > > opinion on this. Pre-built binaries certainly add usability, but I am > > not > > > > sure how those binaries should be tested afterwards. > > > > > > > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov <akuznet...@apache.org > >: > > > > > > > > > I'm +1 for "SLIM" it is a common name in Docker world. > > > > > > > > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <mr.wei...@gmail.com> > > > wrote: > > > > > > > > > > > +1 for slim binary > > > > > > Plus docker-slim > > > > > > Plus RPM / DEB packages modularisation like PHP distribution — > with > > > > core > > > > > > and lots of integrations / modules. > > > > > > > > > > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > I think we should name it "core" since we already have > > ignite-core > > > > and > > > > > it > > > > > > > will be confusing. Maybe we should go full 00s and call it > > "lite"? > > > > > > > > > > > > > > I also think we should keep both .Net and C++. .Net is runnable > > out > > > > of > > > > > > box > > > > > > > which is awesome, and C++ needs building but it is rather small > > in > > > > > source > > > > > > > form. > > > > > > > > > > > > > > I also suggest a different change to build process. Let's ship > > C++ > > > > with > > > > > > > automake, etc, already run, for all binary packaging options? > > > WDYT? I > > > > > can > > > > > > > assist in build process tuning. > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda <dma...@apache.org>: > > > > > > > > > > > > > >> Alex, > > > > > > >> > > > > > > >> I'm on your end and support the proposal. Could you also > clarify > > > if > > > > > you > > > > > > >> suggest we keeping or removing C++ and .NET thick clients? > > > > > > >> > > > > > > >> Speaking of the naming, how about titling such packages as > > 'core' > > > > > > instead > > > > > > >> of 'slim', i.e., 'apache-ignite-core-{version}'? > > > > > > >> > > > > > > >> > > > > > > >> - > > > > > > >> Denis > > > > > > >> > > > > > > >> > > > > > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev < > > > > > > ilya.kasnach...@gmail.com > > > > > > >>> > > > > > > >> wrote: > > > > > > >> > > > > > > >>> Hello! > > > > > > >>> > > > > > > >>> Pavel, I believe these JARs are fully covered by the list of > > > > modules > > > > > > >>> specified above. > > > > > > >>> > > > > > > >>> Regards, > > > > > > >>> -- > > > > > > >>> Ilya Kasnacheev > > > > > > >>> > > > > > > >>> > > > > > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn < > > > ptupit...@apache.org > > > > >: > > > > > > >>> > > > > > > >>>> I like the idea, current distribution is certainly too big. > > > > > > >>>> > > > > > > >>>> Here is a list of jar files we include in NuGet package: > > > > > > >>>> > > > > > > >>>> cache-api-1.0.0.jar > > > > > > >>>> commons-codec-1.11.jar > > > > > > >>>> commons-logging-1.1.1.jar > > > > > > >>>> h2-1.4.197.jar > > > > > > >>>> ignite-core-2.9.0-SNAPSHOT.jar > > > > > > >>>> ignite-indexing-2.9.0-SNAPSHOT.jar > > > > > > >>>> ignite-shmem-1.0.0.jar > > > > > > >>>> ignite-spring-2.9.0-SNAPSHOT.jar > > > > > > >>>> lucene-analyzers-common-7.4.0.jar > > > > > > >>>> lucene-core-7.4.0.jar > > > > > > >>>> lucene-queryparser-7.4.0.jar > > > > > > >>>> spring-aop-4.3.18.RELEASE.jar > > > > > > >>>> spring-beans-4.3.18.RELEASE.jar > > > > > > >>>> spring-context-4.3.18.RELEASE.jar > > > > > > >>>> spring-core-4.3.18.RELEASE.jar > > > > > > >>>> spring-expression-4.3.18.RELEASE.jar > > > > > > >>>> spring-jdbc-4.3.18.RELEASE.jar > > > > > > >>>> spring-tx-4.3.18.RELEASE.jar > > > > > > >>>> > > > > > > >>>> Those are required for SQL and Spring configs to work > > properly, > > > > > > >>>> maybe we want to include them into the slim distro as well. > > > > > > >>>> > > > > > > >>>> On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev < > > > > > > >>> ilya.kasnach...@gmail.com > > > > > > >>>>> > > > > > > >>>> wrote: > > > > > > >>>> > > > > > > >>>>> Hello! > > > > > > >>>>> > > > > > > >>>>> This is a reasonable idea. > > > > > > >>>>> > > > > > > >>>>> I think we should also drop benchmarks/ directory from that > > > > build, > > > > > > >> it's > > > > > > >>>> 60M > > > > > > >>>>> of (potentially vulnerable) JARs that are not needed by an > > > > average > > > > > > >>>>> developer's use cases. > > > > > > >>>>> > > > > > > >>>>> Regards, > > > > > > >>>>> -- > > > > > > >>>>> Ilya Kasnacheev > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk < > > > > > > >>>> alexey.goncha...@gmail.com > > > > > > >>>>>> : > > > > > > >>>>> > > > > > > >>>>>> Igniters, > > > > > > >>>>>> > > > > > > >>>>>> I would like to discuss with the community a possibility > to > > > > create > > > > > > >>>>>> additional 'slim' binary releases and docker images for > > Apache > > > > > > >>> Ignite. > > > > > > >>>>> The > > > > > > >>>>>> reason is two-fold: > > > > > > >>>>>> * The full set of 3rd party libraries distributed with > > Apache > > > > > > >> Ignite > > > > > > >>>>> looks > > > > > > >>>>>> too large for me. I know there is an ongoing activity > > towards > > > > more > > > > > > >>>> clear > > > > > > >>>>>> Ignite modularization [1][2][3], but this seems to be > quite > > a > > > > long > > > > > > >>>>> process. > > > > > > >>>>>> On the other hand, creating a slim release may give an > > > immediate > > > > > > >>>> benefit > > > > > > >>>>> to > > > > > > >>>>>> the users who are interested in a smaller image. For > > example, > > > > > > >>> removing > > > > > > >>>>> the > > > > > > >>>>>> benchmarks alone from the binary release saves 80M. > > > > > > >>>>>> * As Ilya Kasnacheev demonstrated [4], the more 3rd party > > > > > > >> libraries > > > > > > >>> we > > > > > > >>>>>> have, the more potential vulnerabilities will show up in > > audit > > > > > > >> tools. > > > > > > >>>>> This > > > > > > >>>>>> may be a formal barrier for Apache Ignite adoption and > > moving > > > to > > > > > > >>>>> production > > > > > > >>>>>> for many users. Having a slim image with the minimum > number > > of > > > > > > >>>>> dependencies > > > > > > >>>>>> (yet complete enough to fit the majority of use-cases) > > > > > > >> significantly > > > > > > >>>>>> reduces this risk. > > > > > > >>>>>> > > > > > > >>>>>> I wonder what community thinks regarding this idea? Given > > the > > > > > > >> recent > > > > > > >>>>> study > > > > > > >>>>>> of Apache Ignite use-cases, I suggest the following list > of > > > > > modules > > > > > > >>> to > > > > > > >>>> be > > > > > > >>>>>> included to the slim release/image (a subject to discuss, > of > > > > > > >> course): > > > > > > >>>>>> * ignite-core > > > > > > >>>>>> * ignite-indexing > > > > > > >>>>>> * ignite-rest-http > > > > > > >>>>>> * ignite-spring > > > > > > >>>>>> * ignite-log4j > > > > > > >>>>>> * ignite-log4j2 > > > > > > >>>>>> * ignite-slf4j > > > > > > >>>>>> * ignite-urideploy > > > > > > >>>>>> * ignite-kubernetes > > > > > > >>>>>> * ignite-opencensus > > > > > > >>>>>> > > > > > > >>>>>> [1] > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html > > > > > > >>>>>> [2] > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html > > > > > > >>>>>> [3] > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html > > > > > > >>>>>> [4] > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 > > > > > > >>>>>> > > > > > > >>>>>> --AG > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Alexey Kuznetsov > > > > > > > > > > > > > > >
