Craig, Can you describe in more detail your use-cases for versioning of services, and why you feel they are not well supported at present?
A service is versioned according to the exported package containing its interface. If you have services published under the org.example.api.IService interface, then you can version them by exporting different versions of the org.example.api package from different bundles. This allows for API evolution to occur while ensuring that clients get objects that are compatible with their expectations. There is no need to add versioning to service instances because clients should not be aware of the implementation class. Regards, Neil On Wed, Dec 30, 2009 at 3:12 PM, Craig Phillips <[email protected]> wrote: > 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. > _____________________________________________________________________ > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
