I'll wade in, both on horizontal and vertical... First of all, I have a piece of "wisdom" - don't get yourself in to something you can't get yourself out of; A la declarative services / service component run time and/or iPOJO, you can construct a horizontal/vertical "swath" of service code that is essentially POJO... I can scrap the PDE nightmare let alone the Maven nightmares and use simple plain old java projects of any variation, be it vi/make or whatever IDE flavor of the month and build means of your choice; Now you can pick up and move all your code to another platform and simply facilitate the framework pieces underneath (where is that distributed OSGi?, BTW); While I'm on the subject of "build", a couple things to point out: A. Once a bundle is built, it does not ever have to be rebuilt; From that point forward, ALL dependencies are run time; You do not import (venture in to a contract) if you do not know the contract -- meaning, if there is no guarantee of when breakage occurs, you wire to a specific version of dependency only; B. I modified Felix, sort of one-off for the time being, that facilitates "source bundles" - meaning, there is no build; The framework is the convention (more on that later) and, thus, the framework does the build; In my demo case, I have the system bundle doing the build; However, I have progressed to the notion of a "builder registry" where you can bundle-ize C++ source code, let alone java source code, as well as other languages such as scala and groovy (just think, versioned source of groovy or jruby); Anyway, that's slightly off topic... So, I am very much against the "mount everest" effect (excessive vertical-ization); As for horizontal, jar-hell is enough of a motive to move on; I tend to never embed jar's inside of jar's; Everything is a properly versioned bundle; I also separate API from IMPL, something I don't see happening officially; Meaning, API bundles are their own separate entity with no service(s) exposed; Speaking of which, where is versioning of services? I end up having to put a version moniker in the service name to cover for this deficiency in the spec (there are a LOT of deficiencies in the OSGi spec and I'm past the point of frustration trying to get modifications to the spec... talk about mount everest... deep breath); When it comes to vertical, let's just say I don't like stacking bricks more than a handful of layers; Well, that's a good starting point to push the dialog... Happy new year to all, Craig Phillips, Praxis...
________________________________ From: [email protected] on behalf of komal gohil Sent: Wed 12/30/2009 4:46 AM To: [email protected] Subject: [osgi-dev] osgi-vertical modularity How does OSGi achieves vertical modularity? What is the meaning of vertical modularity in terms of OSGi? -komal _____________________________________________________________________ This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at [email protected] and delete this mail. _____________________________________________________________________
<<winmail.dat>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
