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 <aba...@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 <ukohlme...@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 > > > >
