Re: Ignite Modularization
Denis, > I think this should be optional. Do you think we need to do it in the first > instance In my opinion we should at least have a solid understanding of the subject. I think it worth having a separate discussion regarding Java 9 modules. Today java modular subsystem seems to be not widely adopted yet. And many Java library developers are satisfied delivering their jars to be used as automatic modules. I think that today Java 8 is the most widely used version. But the situation can change soon and we should keep our eyes peeled. вт, 2 июл. 2019 г. в 00:39, Denis Magda : > > Hi Ivan, > > Thanks for looking into this. > > 1. I did not get from IEP whether Thin Clients have a separate > > repository and a release lifecycle or not. > > > Sorry for the confusion. Yes, such clients have to be in separate repos and > might have their own lifecycles. Updated the wiki. > > > > 2. Are we going to exclude tests for unsupported modules from Ignite > > TeamCity? > > > Yes, that's my thinking, an unsupported integration won't be part of Ignite > modular ecosystem and won't be tested by the community. Any objections? > > > > 3. Will we adress implementing Java 9+ modules during that process? > > > I think this should be optional. Do you think we need to do it in the > first instance? > > - > Denis > > > On Sun, Jun 30, 2019 at 10:45 PM Павлухин Иван wrote: > > > Hi Denis, > > > > I fully support the idea. Could you please clarify on following points: > > 1. I did not get from IEP whether Thin Clients have a separate > > repository and a release lifecycle or not. > > 2. Are we going to exclude tests for unsupported modules from Ignite > > TeamCity? > > 3. Will we adress implementing Java 9+ modules during that process? > > > > чт, 27 июн. 2019 г. в 18:11, Denis Magda : > > > > > > Ignite developers and users, > > > > > > I'd like us to consider Ignite modularization as part of Ignite 3.0 > > > timeframe. Presently, Ignite codebase mixes both core capabilities with > > 3rd > > > party integrations. It leads to the following: > > > > > >- Cumbersome and continuously growing codebase with many 3rd-party > > >dependencies. > > >- Some of the integrations are questionable and should no longer be > > >supported by the community at all. > > >- Integrations evolution is bound to Ignite release cycles even though > > >no changes are needed in the core. > > >- Ignite community has to support everything (test, release, fix, > > >continue development) which requires to have particular integration > > experts > > >on a permanent basis - doesn't work. > > > > > > Here is an IEP: > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization > > > > > > Please review it, share feedback. Pay attention to the list of > > integrations > > > that should no longer be supported by the community. > > > > > > > > > - > > > Denis > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin
Re: Ignite Modularization
Hi Ivan, Thanks for looking into this. 1. I did not get from IEP whether Thin Clients have a separate > repository and a release lifecycle or not. Sorry for the confusion. Yes, such clients have to be in separate repos and might have their own lifecycles. Updated the wiki. > 2. Are we going to exclude tests for unsupported modules from Ignite > TeamCity? Yes, that's my thinking, an unsupported integration won't be part of Ignite modular ecosystem and won't be tested by the community. Any objections? > 3. Will we adress implementing Java 9+ modules during that process? I think this should be optional. Do you think we need to do it in the first instance? - Denis On Sun, Jun 30, 2019 at 10:45 PM Павлухин Иван wrote: > Hi Denis, > > I fully support the idea. Could you please clarify on following points: > 1. I did not get from IEP whether Thin Clients have a separate > repository and a release lifecycle or not. > 2. Are we going to exclude tests for unsupported modules from Ignite > TeamCity? > 3. Will we adress implementing Java 9+ modules during that process? > > чт, 27 июн. 2019 г. в 18:11, Denis Magda : > > > > Ignite developers and users, > > > > I'd like us to consider Ignite modularization as part of Ignite 3.0 > > timeframe. Presently, Ignite codebase mixes both core capabilities with > 3rd > > party integrations. It leads to the following: > > > >- Cumbersome and continuously growing codebase with many 3rd-party > >dependencies. > >- Some of the integrations are questionable and should no longer be > >supported by the community at all. > >- Integrations evolution is bound to Ignite release cycles even though > >no changes are needed in the core. > >- Ignite community has to support everything (test, release, fix, > >continue development) which requires to have particular integration > experts > >on a permanent basis - doesn't work. > > > > Here is an IEP: > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization > > > > Please review it, share feedback. Pay attention to the list of > integrations > > that should no longer be supported by the community. > > > > > > - > > Denis > > > > -- > Best regards, > Ivan Pavlukhin >
Re: Ignite Modularization
Hi Denis, I fully support the idea. Could you please clarify on following points: 1. I did not get from IEP whether Thin Clients have a separate repository and a release lifecycle or not. 2. Are we going to exclude tests for unsupported modules from Ignite TeamCity? 3. Will we adress implementing Java 9+ modules during that process? чт, 27 июн. 2019 г. в 18:11, Denis Magda : > > Ignite developers and users, > > I'd like us to consider Ignite modularization as part of Ignite 3.0 > timeframe. Presently, Ignite codebase mixes both core capabilities with 3rd > party integrations. It leads to the following: > >- Cumbersome and continuously growing codebase with many 3rd-party >dependencies. >- Some of the integrations are questionable and should no longer be >supported by the community at all. >- Integrations evolution is bound to Ignite release cycles even though >no changes are needed in the core. >- Ignite community has to support everything (test, release, fix, >continue development) which requires to have particular integration experts >on a permanent basis - doesn't work. > > Here is an IEP: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization > > Please review it, share feedback. Pay attention to the list of integrations > that should no longer be supported by the community. > > > - > Denis -- Best regards, Ivan Pavlukhin
