Hello! It is currently included.
Maxim, can you prepare a slim release package based on your generic release procedures? We could take a look at it and then perhaps add it to downloads page officially. What do you think? Regards, -- Ilya Kasnacheev пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov <mmu...@apache.org>: > Ilya, > > `ignite-compress` is necessary for `wal page snapshot compression` [1] > which in turn shows very good performance results. So, I suppose, it's > better to include it to the "slim" binary. > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > wrote: > > > > Hello! > > > > I added these because they are infrastructural to Ignite, as opposed to > > integrations. They are also both very slim. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < > > stephen.darling...@gridgain.com>: > > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very > few > > > people who use either. > > > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > > 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 > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > >
