You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Павлухин Иван <vo...@gmail.com> on 2019/07/01 05:45:36 UTC
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 <dm...@apache.org>:
>
> 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
Posted by Павлухин Иван <vo...@gmail.com>.
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 <dm...@apache.org>:
>
> 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 Павлухин Иван <vo...@gmail.com> 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 <dm...@apache.org>:
> > >
> > > 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
Posted by Denis Magda <dm...@apache.org>.
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 Павлухин Иван <vo...@gmail.com> 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 <dm...@apache.org>:
> >
> > 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
>