You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2017/03/16 16:34:12 UTC
Re: [gemfire-dev] Geode Modularization Proposal
Looks good! I’m very interested in adding a well-defined extension mechanism to geode. IMO, that is an important characteristic of successful open source communities. Looking forward to more details :-)
Anthony
> On Mar 15, 2017, at 10:04 AM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
> Hi there Guys,
>
> The first high-level proposal on Geode modularization has been posted: https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Geode+Modularization.
>
> Please look through this. It is neither a hard or long read BUT it is the precursor to the more detailed proposal.
>
> What is asked of all dev's is that they take a critical look at the code they are working on and start identifying module boundaries. This identification and implementation process is the most important piece to the whole modularization process. Without the identification work, all efforts to have bootstrapping, DI, streaming, reactive, messaging frameworks is an exercise in futility.
>
> If there is any doubt about the size of a module, err on the side of caution... Smaller is better. If a piece of functionality could plausibly be replaced with another implementation, it is a strong candidate for a module.
>
> Over the next few days a more detailed implementation approach will be proposed. In conjunction to that proposal, a register of modules/potential modules will be started. This way we can easily identify modules, no matter how small.
>
> --Udo
>
Re: [gemfire-dev] Geode Modularization Proposal
Posted by Jacob Barrett <jb...@pivotal.io>.
Yes OSGI containers were a nightmare! Take a peak over at JBoss Modules
[1]. I used this extensively in a previous life and it was a cinch to have
different versions of jars deployed in the same application container.
[1] https://github.com/jboss-modules/jboss-modules
On Thu, Mar 16, 2017 at 11:21 AM Dan Smith <ds...@pivotal.io> wrote:
> Nice! Also looking forward to seeing some more details.
>
> I like the goals you've laid out, but I do have some reservations about the
> classloader isolation goal. In my experience containers that do classloader
> isolation tend to cause ton of headaches for users - I'm looking at you,
> OSGI.
>
> -Dan
>
> On Thu, Mar 16, 2017 at 9:34 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > Looks good! I’m very interested in adding a well-defined extension
> > mechanism to geode. IMO, that is an important characteristic of
> successful
> > open source communities. Looking forward to more details :-)
> >
> > Anthony
> >
> > > On Mar 15, 2017, at 10:04 AM, Udo Kohlmeyer <uk...@pivotal.io>
> > wrote:
> > >
> > > Hi there Guys,
> > >
> > > The first high-level proposal on Geode modularization has been posted:
> > https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Geode+
> > Modularization.
> > >
> > > Please look through this. It is neither a hard or long read BUT it is
> > the precursor to the more detailed proposal.
> > >
> > > What is asked of all dev's is that they take a critical look at the
> code
> > they are working on and start identifying module boundaries. This
> > identification and implementation process is the most important piece to
> > the whole modularization process. Without the identification work, all
> > efforts to have bootstrapping, DI, streaming, reactive, messaging
> > frameworks is an exercise in futility.
> > >
> > > If there is any doubt about the size of a module, err on the side of
> > caution... Smaller is better. If a piece of functionality could plausibly
> > be replaced with another implementation, it is a strong candidate for a
> > module.
> > >
> > > Over the next few days a more detailed implementation approach will be
> > proposed. In conjunction to that proposal, a register of
> modules/potential
> > modules will be started. This way we can easily identify modules, no
> matter
> > how small.
> > >
> > > --Udo
> > >
> >
> >
>
Re: [gemfire-dev] Geode Modularization Proposal
Posted by Dan Smith <ds...@pivotal.io>.
Nice! Also looking forward to seeing some more details.
I like the goals you've laid out, but I do have some reservations about the
classloader isolation goal. In my experience containers that do classloader
isolation tend to cause ton of headaches for users - I'm looking at you,
OSGI.
-Dan
On Thu, Mar 16, 2017 at 9:34 AM, Anthony Baker <ab...@pivotal.io> wrote:
> Looks good! I’m very interested in adding a well-defined extension
> mechanism to geode. IMO, that is an important characteristic of successful
> open source communities. Looking forward to more details :-)
>
> Anthony
>
> > On Mar 15, 2017, at 10:04 AM, Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
> >
> > Hi there Guys,
> >
> > The first high-level proposal on Geode modularization has been posted:
> https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Geode+
> Modularization.
> >
> > Please look through this. It is neither a hard or long read BUT it is
> the precursor to the more detailed proposal.
> >
> > What is asked of all dev's is that they take a critical look at the code
> they are working on and start identifying module boundaries. This
> identification and implementation process is the most important piece to
> the whole modularization process. Without the identification work, all
> efforts to have bootstrapping, DI, streaming, reactive, messaging
> frameworks is an exercise in futility.
> >
> > If there is any doubt about the size of a module, err on the side of
> caution... Smaller is better. If a piece of functionality could plausibly
> be replaced with another implementation, it is a strong candidate for a
> module.
> >
> > Over the next few days a more detailed implementation approach will be
> proposed. In conjunction to that proposal, a register of modules/potential
> modules will be started. This way we can easily identify modules, no matter
> how small.
> >
> > --Udo
> >
>
>