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 > > >