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