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