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