Slim binary release and docker image for Apache Ignite

[Alexey Goncharuk]

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

[Ilya Kasnacheev]

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 <[hidden email]>:

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

[Pavel Tupitsyn]

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 <[hidden email]>
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 <[hidden email]
> >:
>
> > 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
> >
>

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <[hidden email]
> >
> 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 <
> [hidden email]
> > >:
> >
> > > 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
> > >
> >
>

[dmagda]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <
> [hidden email]
> > >
> > 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 <
> > [hidden email]
> > > >:
> > >
> > > > 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
> > > >
> > >
> >
>

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <[hidden email]
> >
> 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 <[hidden email]>:
> >
> > > 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 <
> > [hidden email]
> > > >
> > > 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 <
> > > [hidden email]
> > > > >:
> > > >
> > > > > 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
> > > > >
> > > >
> > >
> >
>

[vveider]

+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 <[hidden email]> 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 <[hidden email]>:
>
>> 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 <[hidden email]
>>>
>> 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 <[hidden email]>:
>>>
>>>> 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 <
>>> [hidden email]
>>>>>
>>>> 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 <
>>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> 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]

I'm +1 for "SLIM" it is a common name in Docker world.

On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> >> 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 <
> [hidden email]
> >>>
> >> 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 <[hidden email]>:
> >>>
> >>>> 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 <
> >>> [hidden email]
> >>>>>
> >>>> 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 <
> >>>> [hidden email]
> >>>>>> :
> >>>>>
> >>>>>> 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

[Alexey Goncharuk]

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 <[hidden email]>:

> I'm +1 for "SLIM" it is a common name in Docker world.
>
> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > >> 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 <
> > [hidden email]
> > >>>
> > >> 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 <[hidden email]>:
> > >>>
> > >>>> 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 <
> > >>> [hidden email]
> > >>>>>
> > >>>> 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 <
> > >>>> [hidden email]
> > >>>>>> :
> > >>>>>
> > >>>>>> 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
>

[Igor Sapego-2]

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 <
[hidden email]> 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 <[hidden email]>:
>
> > I'm +1 for "SLIM" it is a common name in Docker world.
> >
> > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]> 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 <[hidden email]
> >
> > > 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 <[hidden email]>:
> > > >
> > > >> 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 <
> > > [hidden email]
> > > >>>
> > > >> 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 <[hidden email]
> >:
> > > >>>
> > > >>>> 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 <
> > > >>> [hidden email]
> > > >>>>>
> > > >>>> 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 <
> > > >>>> [hidden email]
> > > >>>>>> :
> > > >>>>>
> > > >>>>>> 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
> >
>

[Alexey Goncharuk]

Got it, sounds good!
Should we consider the list of modules included in the slim package
finalized?

чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]>:
> >
> > > I'm +1 for "SLIM" it is a common name in Docker world.
> > >
> > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
> 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 <
> [hidden email]
> > >
> > > > 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 <[hidden email]>:
> > > > >
> > > > >> 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 <
> > > > [hidden email]
> > > > >>>
> > > > >> 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 <
> [hidden email]
> > >:
> > > > >>>
> > > > >>>> 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 <
> > > > >>> [hidden email]
> > > > >>>>>
> > > > >>>> 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 <
> > > > >>>> [hidden email]
> > > > >>>>>> :
> > > > >>>>>
> > > > >>>>>> 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
> > >
> >
>

[dmagda]

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 <
[hidden email]> wrote:

> Got it, sounds good!
> Should we consider the list of modules included in the slim package
> finalized?
>
> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <[hidden email]>:
> > >
> > > > I'm +1 for "SLIM" it is a common name in Docker world.
> > > >
> > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
> > 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 <
> > [hidden email]
> > > >
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > >> 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 <
> > > > > [hidden email]
> > > > > >>>
> > > > > >> 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 <
> > [hidden email]
> > > >:
> > > > > >>>
> > > > > >>>> 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 <
> > > > > >>> [hidden email]
> > > > > >>>>>
> > > > > >>>> 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 <
> > > > > >>>> [hidden email]
> > > > > >>>>>> :
> > > > > >>>>>
> > > > > >>>>>> 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
> > > >
> > >
> >
>

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <
> [hidden email]> wrote:
>
> > Got it, sounds good!
> > Should we consider the list of modules included in the slim package
> > finalized?
> >
> > чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <[hidden email]
> >:
> > > >
> > > > > I'm +1 for "SLIM" it is a common name in Docker world.
> > > > >
> > > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >
> > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > >> 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 <
> > > > > > [hidden email]
> > > > > > >>>
> > > > > > >> 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 <
> > > [hidden email]
> > > > >:
> > > > > > >>>
> > > > > > >>>> 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 <
> > > > > > >>> [hidden email]
> > > > > > >>>>>
> > > > > > >>>> 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 <
> > > > > > >>>> [hidden email]
> > > > > > >>>>>> :
> > > > > > >>>>>
> > > > > > >>>>>> 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
> > > > >
> > > >
> > >
> >
>

[sdarlington]

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 <[hidden email]> 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 <[hidden email]>:
>
>> 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 <
>> [hidden email]> wrote:
>>
>>> Got it, sounds good!
>>> Should we consider the list of modules included in the slim package
>>> finalized?
>>>
>>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
>>>
>>>> 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 <
>>>> [hidden email]> 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 <[hidden email]
>>> :
>>>>>
>>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
>>>>>>
>>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
>>>> 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 <
>>>> [hidden email]
>>>>>>
>>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>> 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 <
>>>> [hidden email]
>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>

[Ilya Kasnacheev]

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 <
[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> >> 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 <
> >> [hidden email]> wrote:
> >>
> >>> Got it, sounds good!
> >>> Should we consider the list of modules included in the slim package
> >>> finalized?
> >>>
> >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> >>>
> >>>> 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 <
> >>>> [hidden email]> 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 <[hidden email]
> >>> :
> >>>>>
> >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
> >>>>>>
> >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
> >>>> 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 <
> >>>> [hidden email]
> >>>>>>
> >>>>>>> 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 <[hidden email]>:
> >>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>> [hidden email]
> >>>>>>>>>>
> >>>>>>>>> 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 <
> >>>> [hidden email]
> >>>>>> :
> >>>>>>>>>>
> >>>>>>>>>>> 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 <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>>>
> >>>>>>>>>>> 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 <
> >>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>> :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
>

[Maxim Muzafarov]

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 <[hidden email]> 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 <
> [hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > >> 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 <
> > >> [hidden email]> wrote:
> > >>
> > >>> Got it, sounds good!
> > >>> Should we consider the list of modules included in the slim package
> > >>> finalized?
> > >>>
> > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> > >>>
> > >>>> 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 <
> > >>>> [hidden email]> 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 <[hidden email]
> > >>> :
> > >>>>>
> > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
> > >>>>>>
> > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <[hidden email]>
> > >>>> 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 <
> > >>>> [hidden email]
> > >>>>>>
> > >>>>>>> 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 <[hidden email]>:
> > >>>>>>>>
> > >>>>>>>>> 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 <
> > >>>>>>> [hidden email]
> > >>>>>>>>>>
> > >>>>>>>>> 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 <
> > >>>> [hidden email]
> > >>>>>> :
> > >>>>>>>>>>
> > >>>>>>>>>>> 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 <
> > >>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>
> > >>>>>>>>>>> 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 <
> > >>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>> :
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 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
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
> >

[Ilya Kasnacheev]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > >> 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 <
> > > >> [hidden email]> wrote:
> > > >>
> > > >>> Got it, sounds good!
> > > >>> Should we consider the list of modules included in the slim package
> > > >>> finalized?
> > > >>>
> > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> > > >>>
> > > >>>> 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 <
> > > >>>> [hidden email]> 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 <
> [hidden email]
> > > >>> :
> > > >>>>>
> > > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
> > > >>>>>>
> > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <
> [hidden email]>
> > > >>>> 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 <
> > > >>>> [hidden email]
> > > >>>>>>
> > > >>>>>>> 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 <[hidden email]>:
> > > >>>>>>>>
> > > >>>>>>>>> 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 <
> > > >>>>>>> [hidden email]
> > > >>>>>>>>>>
> > > >>>>>>>>> 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 <
> > > >>>> [hidden email]
> > > >>>>>> :
> > > >>>>>>>>>>
> > > >>>>>>>>>>> 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 <
> > > >>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> 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 <
> > > >>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>> :
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> 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
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> > >
>

[Maxim Muzafarov]

Ilya,

It is not "mine" generic release procedures they are "ours" :-)
I've created the issue [1] based on current discussion thread.


[1] https://issues.apache.org/jira/browse/IGNITE-12765

On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev <[hidden email]> wrote:

>
> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <
> > > [hidden email]>:
> > >
> > > > 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 <[hidden email]>
> > > > 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 <[hidden email]>:
> > > > >
> > > > >> 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 <
> > > > >> [hidden email]> wrote:
> > > > >>
> > > > >>> Got it, sounds good!
> > > > >>> Should we consider the list of modules included in the slim package
> > > > >>> finalized?
> > > > >>>
> > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> > > > >>>
> > > > >>>> 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 <
> > > > >>>> [hidden email]> 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 <
> > [hidden email]
> > > > >>> :
> > > > >>>>>
> > > > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
> > > > >>>>>>
> > > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <
> > [hidden email]>
> > > > >>>> 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 <
> > > > >>>> [hidden email]
> > > > >>>>>>
> > > > >>>>>>> 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 <[hidden email]>:
> > > > >>>>>>>>
> > > > >>>>>>>>> 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 <
> > > > >>>>>>> [hidden email]
> > > > >>>>>>>>>>
> > > > >>>>>>>>> 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 <
> > > > >>>> [hidden email]
> > > > >>>>>> :
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> 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 <
> > > > >>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>> 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 <
> > > > >>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>> :
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> 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
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > > >
> >

[Ilya Kasnacheev]

Hello!

I understand that procedures are courtesy Apache Ignite, but I assume that
you went through them and can now repeat them reproducibly.

Thank you!
--
Ilya Kasnacheev


вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov <[hidden email]>:

> Ilya,
>
> It is not "mine" generic release procedures they are "ours" :-)
> I've created the issue [1] based on current discussion thread.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12765
>
> On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev <[hidden email]>
> wrote:
> >
> > 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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]>
> > > 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 <
> > > > [hidden email]>:
> > > >
> > > > > 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 <
> [hidden email]>
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > >> 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 <
> > > > > >> [hidden email]> wrote:
> > > > > >>
> > > > > >>> Got it, sounds good!
> > > > > >>> Should we consider the list of modules included in the slim
> package
> > > > > >>> finalized?
> > > > > >>>
> > > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]>:
> > > > > >>>
> > > > > >>>> 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 <
> > > > > >>>> [hidden email]> 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 <
> > > [hidden email]
> > > > > >>> :
> > > > > >>>>>
> > > > > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
> > > > > >>>>>>
> > > > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <
> > > [hidden email]>
> > > > > >>>> 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 <
> > > > > >>>> [hidden email]
> > > > > >>>>>>
> > > > > >>>>>>> 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 <
> [hidden email]>:
> > > > > >>>>>>>>
> > > > > >>>>>>>>> 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 <
> > > > > >>>>>>> [hidden email]
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>> 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 <
> > > > > >>>> [hidden email]
> > > > > >>>>>> :
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> 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 <
> > > > > >>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>> 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 <
> > > > > >>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>> :
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> 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
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > > >
> > >
>

[Ilya Kasnacheev]

Hello!

I have just merged slim binary release to master.

I will now try to tweak nightly builds TC suite to build this package also.
It may be broken for some brief period of time.

Regards,
--
Ilya Kasnacheev


вт, 10 мар. 2020 г. в 18:24, Ilya Kasnacheev <[hidden email]>:

> Hello!
>
> I understand that procedures are courtesy Apache Ignite, but I assume that
> you went through them and can now repeat them reproducibly.
>
> Thank you!
> --
> Ilya Kasnacheev
>
>
> вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov <[hidden email]>:
>
>> Ilya,
>>
>> It is not "mine" generic release procedures they are "ours" :-)
>> I've created the issue [1] based on current discussion thread.
>>
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-12765
>>
>> On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev <[hidden email]>
>> wrote:
>> >
>> > 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 <[hidden email]>:
>> >
>> > > 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 <
>> [hidden email]>
>> > > 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 <
>> > > > [hidden email]>:
>> > > >
>> > > > > 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 <
>> [hidden email]>
>> > > > > 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 <[hidden email]>:
>> > > > > >
>> > > > > >> 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 <
>> > > > > >> [hidden email]> wrote:
>> > > > > >>
>> > > > > >>> Got it, sounds good!
>> > > > > >>> Should we consider the list of modules included in the slim
>> package
>> > > > > >>> finalized?
>> > > > > >>>
>> > > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <[hidden email]
>> >:
>> > > > > >>>
>> > > > > >>>> 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 <
>> > > > > >>>> [hidden email]> 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 <
>> > > [hidden email]
>> > > > > >>> :
>> > > > > >>>>>
>> > > > > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world.
>> > > > > >>>>>>
>> > > > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov <
>> > > [hidden email]>
>> > > > > >>>> 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 <
>> > > > > >>>> [hidden email]
>> > > > > >>>>>>
>> > > > > >>>>>>> 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 <
>> [hidden email]>:
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>> 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 <
>> > > > > >>>>>>> [hidden email]
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>> 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 <
>> > > > > >>>> [hidden email]
>> > > > > >>>>>> :
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>>> 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 <
>> > > > > >>>>>>>>>> [hidden email]
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>> 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 <
>> > > > > >>>>>>>>>>> [hidden email]
>> > > > > >>>>>>>>>>>>> :
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> 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
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > >
>>
>