incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject Re: Proposal to use OSGi for component modularity
Date Fri, 01 Jun 2012 10:52:41 GMT
Hi Marcel...

On Fri, Jun 1, 2012 at 2:10 AM, Marcel Offermans <
marcel.offermans@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message