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.
- Using a known framework hopefully will reduce questions about how
CloudStack's plugins work, easing the developer learning curve.
- Provide tougher modularity checks than simply compilation.
If using OSGi does not achieve these functions, I like to know.
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.
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.
Any help in this area to get us started would be great.
--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
