You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Norbert Somlai <ns...@gmail.com> on 2010/03/17 14:48:21 UTC

iPOJO vs Blueprint

Hello,

I'm getting somewhat confused about many of the overlapping OSGi
technologies but this one bugs me the most.

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).

However, Blueprint is the 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)? 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?

Since I'm still a newbie, maybe the whole question is dumb, in that case I
apologize. :-)

Norbert
-- 
View this message in context: http://old.nabble.com/iPOJO-vs-Blueprint-tp27932355p27932355.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: iPOJO vs Blueprint

Posted by Clement Escoffier <cl...@gmail.com>.
Hello,

On 17.03.2010, at 15:49, Marcel Offermans wrote:

> 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.

Right, we go on the development and support. The 1.6 is close and the 2.0 is also in the wires.
iPOJO works perfectly on the top of Karaf. Regarding Aries, the provided services can be used by iPOJO, and iPOJO already provides almost the same set of extensions (as transactions ...).

> 
>> 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.

Right, iPOJO does consider the bundle as a deployment unit, not as a scope (because it's not a scope). But as said by Marcel, we support composition intra and cross bundle (just depends where are the factories). 


Regards,

Clement


> 
>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: iPOJO vs Blueprint

Posted by Marcel Offermans <ma...@luminis.nl>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org