Hello Norbert, On Mar 17, 2010, at 14:48 , Norbert Somlai wrote:
> I'm getting somewhat confused about many of the overlapping OSGi > technologies but this one bugs me the most. Ok. > As far as I can see, iPOJO is a project originating from the era before > Blueprint is ever invented to make development easier, and iPOJO and Spring > IoC > Blueprint (iPOJO provides many other extras). In fact, if you look closer, there are many different solutions available that allow you to manage service dependencies. Just looking at what's available inside the Felix project: Declarative Services (implementing the compendium specification), iPOJO, Dependency Manager. Outside of Felix there are some more. Whilst they all mostly solve the same problem, each has their own, unique features. What to use? That of course depends on your preference, the requirements of your particular project, etc. Of course you are not even forced to "choose one", you can mix and match. All of them in the end support the standard OSGi services model. > However, Blueprint is the standard. Small correction, it is a standard. :) > So the question arises: what will be the > evolution path of iPOJO (especially in the light of other projects such as > Karaf and Aries)? Clement can probably answer questions about iPOJO best, but my guess would be that he keeps evolving and supporting it. > Will it always focus to the outer interface of the bundles > or will it come to a point where it gets integrated with Blueprint and the > internal structure of the bundles will also specified in, for example, > metadata.xml? I don't think iPOJO only deals with the "outer interface" of the bundles, it also supports composition, dependencies and injection inside the bundle. > Since I'm still a newbie, maybe the whole question is dumb, in that case I > apologize. :-) It's not a dumb question at all. It probably is hard to get a good overview of all available alternatives (as far as I know there's no site explaining and comparing all of them). Hope this helps a bit. :) Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
