On Mon, Jun 4, 2012 at 9:12 PM, Alex Huang <alex.hu...@citrix.com> wrote:
> Hi All,
>
> I like to summarize exactly what we want to use OSGi for. To Mohammad's
> point, CloudStack will be splitting out most of its plugins into separate
> jar files and put in appropriate build dependencies. I will send out a
> separate proposal for that. We will not be converting everything within
> CloudStack to be based on OSGi framework, only the plugins. I think that's
> sufficient for code isolation and modularity. The reason I brought up OSGi
> is for other things:
>
>
> - As plugins developed by others grow, there will be question of
> having separate versioning for different plugins and cloudstack and
> therefore independent updates of the jars. I don't believe we will
> dynamically updates the jars but I do believe we need a version
> compatibility to help with deciding which package works with which. This
> is where a framework such as OSGi can be of great help to us.
>
As you say, this is perhaps one of the most compelling reasons: independent
plugin release schedules with version compatibility enforcement at runtime.
OSGi excels at this point.
- Using a known framework hopefully will reduce questions about how
> CloudStack's plugins work, easing the developer learning curve.
>
+1
- Provide tougher modularity checks than simply compilation.
>
> If using OSGi does not achieve these functions, I like to know.
>
>
Yes it does ... you're right on here.
> I think an additional requirement for us will be to use only standard OSGi
> spec. no extensions. That should mean any of the OSGi runtime should work.
>
>
You probably want to primarily stay away from fragments.
> I welcome any help in doing this conversion but I'm unclear as to what
> information I need to provide to the contributors in order to get this
> started.
Usually a coarse to fine grained gradual modularization effort takes place:
making the entire project a component, and moving on to the most high
priority subsystems that need the modularity.
In our case here we might be best off picking one aspect that needs to be
extensible with plugins and do a little experiment there with the support
of the greater OSGi community here. More below on that.
> Any help in this area to get us started would be great.
>
>
I think we should take up offers from folks we have here at Apache. Those
from the Karaf, Ace, and Felix OSGi communities want to help. They can help
as contributors and help coach and answer questions for existing
contributors new to OSGi. I'm sure theres a mixed bag of those that want to
contribute to varying degrees. This way the learning curve can be tackled
quickly with help, and we can grow the community at the same time.
--Alex
>
>
> > -----Original Message-----
> > From: Mohammad Nour El-Din [mailto:nour.moham...@gmail.com]
> > Sent: Friday, June 01, 2012 3:53 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Proposal to use OSGi for component modularity
> >
> > Hi Marcel...
> >
> > On Fri, Jun 1, 2012 at 2:10 AM, Marcel Offermans <
> > marcel.offerm...@luminis.nl> wrote:
> >
> > > Hello Mohammad,
> > >
> > > On May 31, 2012, at 20:36 , Mohammad Nour El-Din wrote:
> > >
> > > > But from what you said Frank, and what others proposed, I think you
> > > > don't need that kind of modularity facilitated by OSGi or like
> > > > technologies, I believe all what we need then is:
> > > >
> > > > 1- Good design
> > >
> > > +1
> > >
> > > > 2- Good documentation about adding new modules/components
> > >
> > > +1
> > >
> > > > 3- Managing modules/components dependencies using maven for
> > example
> > >
> > > I actually don't agree that Maven is a good example of managing
> > > dependencies, for a couple of reasons:
> > >
> > > 1) It manages dependencies between components (jar files with
> > > multiple, often a lot of packages). This is often way too coarse
> > > grained, leading to transitive dependencies that tend to "drag in the
> whole
> > universe".
> > >
> > > 2) It does not allow you to separate API from implementation in an
> > > easy way, meaning you end up depending on some specific
> > implementation
> > > (of for example logging) instead of only depending on the API.
> > >
> > > In stead, the OSGi model (regardless of whether you use OSGi or not)
> > > shares code at the package level, so you can for example depend on
> > > just an API package. Also, it allows you to distinguish between
> > > public/shared packages and private ones.
> > >
> > > > 4- Good code organization to reflect this modularity on code level
> > > > in the repo
> > >
> > > Agreed. In practice though, you will find that if you have no means of
> > > enforcing modularity at runtime, it is hard to prevent people from
> > > doing things that conflict with your nice and modular design.
> > >
> > > So if you're serious about creating a modular architecture, regardless
> > > of the fact that you don't need the dynamic updating at runtime, or
> > > even the versioning, I would still personally use the framework to
> > > simply enforce the good design at runtime. Or, turn it around, what
> > > other technology would you use?
> > >
> > > Another thing to consider: there are no short term benefits of
> > > creating such a modular architecture, in fact it is extra work and it
> > > probably introduces some additional complexity now. In the long term
> > > though, it definitely has benefits, as modular applications tend to be
> > > more easy to maintain a couple of years from now.
> > >
> > > Greetings, Marcel
> > >
> >
> >
> > Very well said and I totally agree with you cause I trust your
> experience with
> > modularity and OSGi, and I didn't mean to compare what I explained with
> > something like what OSGi can do
> >
> > I was just trying to propose a solution which does not need that learning
> > curve which was the concern of some people on this thread
> >
> > But again I agree with you, and Allow me to formulate what has been said
> so
> > far by all of us in these 2 points:
> >
> > 1- Either go the easy way, short learning curve if any, fast result, but
> bad on
> > the long run
> > 2- Go the hard way, (relatively) long learning curve, not so fast result,
> > iterative work out, but excellent on the long run
> >
> > For me I would go the for the 2nd path, not necessarily at once, we can
> take
> > it gradually, Marcel for I trust he can give more insight about the
> > HOW-TO(s) of how to move to a modular system
> >
> > Thoughts/Feedbak/Kicks :D ?
> >
> > --
> > Thanks
> > - Mohammad Nour
> > ----
> > "Life is like riding a bicycle. To keep your balance you must keep
> moving"
> > - Albert Einstein
>
--
Best Regards,
-- Alex
