You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by jie yan <ya...@gmail.com> on 2011/05/25 03:46:09 UTC
iPOJO vs SCR vs Blueprint
I wonder what is the difference between these three component runtime.
Is there the best one which can take over the others, then we could focus
attention on just one solution?
Regards,
drhades
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 05/25/2011 06:00 PM, Marcel Offermans wrote:
> Wouldn't it make more sense to add this to the Felix FAQ instead.
>
> In any case I'd be happy to add Dependency Manager to the list if nobody objects.
Well, we can point to it from any number of places, so I'm not sure if
it matters where it leaves. But feel free to add DM and move it where
you want (just update the iPOJO FAQ to point to it instead).
-> richard
> On May 25, 2011, at 23:16 , Richard S. Hall wrote:
>
>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>> Hi,
>>>
>>> This is good I might link to it, or pinch it for the aries webpage too
>>> if that is ok. When doing that thought I would put some changes into
>>> the blueprint column. The Aries blueprint implementation provides some
>>> value add that would change some of the No's into Yes's.
>> Sure.
>>
>>> One thing though in component lifecycle control you have a Partial
>>> down for blueprint I was wondering what you meant by this.
>> I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-)
>>
>> -> richard
>>
>>> Thanks
>>> Alasdair
>>>
>>>
>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>> compare the features...perhaps I could re-create that table on a web page...
>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>
>>>> It's not perfect, but it is better than nothing. It should eventually
>>>> propagate to our static pages.
>>>>
>>>> Clement, please double check the iPOJO features, since you've added features
>>>> since the book has been published.
>>>>
>>>> -> richard
>>>>
>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>> +1
>>>>>>
>>>>>> Regards,
>>>>>> drhades
>>>>>>
>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>>>>>> wrote:
>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>
>>>>>>>>> I wonder what is the difference between these three component runtime.
>>>>>>>>>
>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>
>>>>>>>>
>>>>>>> I guess everyone like myself is seeing this question occur regularly on
>>>>>>> this
>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>> wiki/web
>>>>>>> page to with the pros and cons.
>>>>>>>
>>>>>>> I myself have many questions and can't really tell which is best for our
>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>> research. However our situation is much more unique since we back
>>>>>>> configuration information needed to wire the server inside a LDIF/LDAP
>>>>>>> based
>>>>>>> backing store. Lots to think about for us.
>>>>>>>
>>>>>>> Excuse the digression on our specific issues but regarding having a page
>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>> many
>>>>>>> of
>>>>>>> our users.
>>>>>>>
>>>>>>> Best,
>>>>>>> Alex
>>>>>>>
>>>
Re: iPOJO vs SCR vs Blueprint
Posted by Marcel Offermans <ma...@luminis.nl>.
Wouldn't it make more sense to add this to the Felix FAQ instead.
In any case I'd be happy to add Dependency Manager to the list if nobody objects.
On May 25, 2011, at 23:16 , Richard S. Hall wrote:
> On 5/25/11 16:26, Alasdair Nottingham wrote:
>> Hi,
>>
>> This is good I might link to it, or pinch it for the aries webpage too
>> if that is ok. When doing that thought I would put some changes into
>> the blueprint column. The Aries blueprint implementation provides some
>> value add that would change some of the No's into Yes's.
>
> Sure.
>
>> One thing though in component lifecycle control you have a Partial
>> down for blueprint I was wondering what you meant by this.
>
> I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-)
>
> -> richard
>
>> Thanks
>> Alasdair
>>
>>
>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>> compare the features...perhaps I could re-create that table on a web page...
>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>
>>> It's not perfect, but it is better than nothing. It should eventually
>>> propagate to our static pages.
>>>
>>> Clement, please double check the iPOJO features, since you've added features
>>> since the book has been published.
>>>
>>> -> richard
>>>
>>>> On 5/25/11 5:26, jie yan wrote:
>>>>> +1
>>>>>
>>>>> Regards,
>>>>> drhades
>>>>>
>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>>>>> wrote:
>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>
>>>>>>>> I wonder what is the difference between these three component runtime.
>>>>>>>>
>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>
>>>>>>>
>>>>>> I guess everyone like myself is seeing this question occur regularly on
>>>>>> this
>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>> wiki/web
>>>>>> page to with the pros and cons.
>>>>>>
>>>>>> I myself have many questions and can't really tell which is best for our
>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>> research. However our situation is much more unique since we back
>>>>>> configuration information needed to wire the server inside a LDIF/LDAP
>>>>>> based
>>>>>> backing store. Lots to think about for us.
>>>>>>
>>>>>> Excuse the digression on our specific issues but regarding having a page
>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>> many
>>>>>> of
>>>>>> our users.
>>>>>>
>>>>>> Best,
>>>>>> Alex
>>>>>>
>>
>>
Re: iPOJO vs SCR vs Blueprint
Posted by jie yan <ya...@gmail.com>.
On Thu, May 26, 2011 at 10:38 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 05/25/2011 09:23 PM, jie yan wrote:
>
>> Maybe that can be called religious flame war, but it's valuable. What we
>> really need in open community is simple and perfect product in technology,
>> but not many repeat manufacturing wheels like some outside companies.
>>
>
> When implementing any software there are design trade-offs as well as
> different focuses and goals. So, even though the wheel may look like a
> reinvention, it is not generally the exact same wheel, only similar. While
> it would be great if we could always agree on a single design and set of
> trade-offs, the likelihood of that is slim.
>
> I agree with that.
The current problem maybe that, we cannot easily see enough information
about the trade-offs of each design and comparisons of them.
We can also dive into the application and implementation of each solution,
to find out the better one, to love and support one of them, or even to
reinvent a better one based on existing design.
While that's quite high cost, if there are no enough comparative information
about design trade-offs that can be easily accessed.
Regards,
drhades
-> richard
>
>
> Regards,
>> drhades
>>
>> -> richard
>>>>
>>>> Thanks
>>>>> Alasdair
>>>>>
>>>>>
>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>
>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>
>>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>>> compare the features...perhaps I could re-create that table on a web
>>>>>>>
>>>>>> page...
>>>
>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>
>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>>> propagate to our static pages.
>>>>>>
>>>>>> Clement, please double check the iPOJO features, since you've added
>>>>>>
>>>>> features
>>>
>>>> since the book has been published.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> drhades
>>>>>>>>
>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<akarasulu@apache.org
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>>>>>>>
>>>>>>>> heavy@ungoverned.org
>>>
>>>> wrote:
>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>
>>>>>>>>>> I wonder what is the difference between these three component
>>>>>>>>>>>
>>>>>>>>>> runtime.
>>>
>>>> They all manage service dependencies. Blueprint and iPOJO provide
>>>>>>>>>>
>>>>>>>>> more
>>>
>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I guess everyone like myself is seeing this question occur
>>>>>>>>> regularly
>>>>>>>>>
>>>>>>>> on
>>>
>>>> this
>>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>>> wiki/web
>>>>>>>>> page to with the pros and cons.
>>>>>>>>>
>>>>>>>>> I myself have many questions and can't really tell which is best
>>>>>>>>> for
>>>>>>>>>
>>>>>>>> our
>>>
>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>>> configuration information needed to wire the server inside a
>>>>>>>>>
>>>>>>>> LDIF/LDAP
>>>
>>>> based
>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>
>>>>>>>>> Excuse the digression on our specific issues but regarding having a
>>>>>>>>>
>>>>>>>> page
>>>
>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>>> many
>>>>>>>>> of
>>>>>>>>> our users.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 05/25/2011 09:23 PM, jie yan wrote:
> Maybe that can be called religious flame war, but it's valuable. What we
> really need in open community is simple and perfect product in technology,
> but not many repeat manufacturing wheels like some outside companies.
When implementing any software there are design trade-offs as well as
different focuses and goals. So, even though the wheel may look like a
reinvention, it is not generally the exact same wheel, only similar.
While it would be great if we could always agree on a single design and
set of trade-offs, the likelihood of that is slim.
-> richard
> Regards,
> drhades
>
>>> -> richard
>>>
>>>> Thanks
>>>> Alasdair
>>>>
>>>>
>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>> compare the features...perhaps I could re-create that table on a web
>> page...
>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>
>>>>>
>>>>>
>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>> propagate to our static pages.
>>>>>
>>>>> Clement, please double check the iPOJO features, since you've added
>> features
>>>>> since the book has been published.
>>>>>
>>>>> -> richard
>>>>>
>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> Regards,
>>>>>>> drhades
>>>>>>>
>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>> heavy@ungoverned.org
>>>>>>>>> wrote:
>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>
>>>>>>>>>> I wonder what is the difference between these three component
>> runtime.
>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
>> more
>>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I guess everyone like myself is seeing this question occur regularly
>> on
>>>>>>>> this
>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>> wiki/web
>>>>>>>> page to with the pros and cons.
>>>>>>>>
>>>>>>>> I myself have many questions and can't really tell which is best for
>> our
>>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>> configuration information needed to wire the server inside a
>> LDIF/LDAP
>>>>>>>> based
>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>
>>>>>>>> Excuse the digression on our specific issues but regarding having a
>> page
>>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>> many
>>>>>>>> of
>>>>>>>> our users.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Alex
>>>>>>>>
>>>>
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/8/11 11:16, Peter Kriens wrote:
> Obviously everybody needs all these goodies you mention. However the choice is to do this in iPOJO with a new "language" and new semantics
Actually, there is no new "language"...the annotations are basically the
same as the ones you like for DS...but, yes, there are some new
semantics, otherwise there'd be no new functionality. :-)
-> richard
> attached to it or do it in Java. I am very familiar with the semantics of Java and the pain of the redundancy in Java over iPOJO in this area has not been high enough to make this switch seem desirable.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 8 jun 2011, at 15:24, Richard S. Hall wrote:
>
>> On 6/8/11 9:13, Peter Kriens wrote:
>>> The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features.
>>>
>>> In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch.
>> Yeah, who needs things like automatic concurrency handling for services or byte-code generated smart service references that eliminate the need to turn everything into a component in order to pass around services throughout your component? It's better to do all that stuff by hand with DS... ;-)
>>
>> -> richard
>>
>> p.s. Sorry, I couldn't resist... :-P
>>
>>> Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> Just stating an incompletely informed opinion here ..
>>>>
>>>> If you want something simple, light-weight and easy to use, go for
>>>> Declarative Services.
>>>>
>>>> If you want elaborate functionality or need something Declarative
>>>> Services does not provide, consider iPojo (I understand it is an
>>>> evolution of Declarative Services, right ?)
>>>>
>>>> If you have a Spring background go for blueprint.
>>>>
>>>> Regards
>>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>>
>>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham<no...@apache.org> wrote:
>>>>>
>>>>>> Alasdair Nottingham
>>>>>>
>>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<he...@ungoverned.org> wrote:
>>>>>>
>>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is good I might link to it, or pinch it for the aries webpage too
>>>>>>>> if that is ok. When doing that thought I would put some changes into
>>>>>>>> the blueprint column. The Aries blueprint implementation provides some
>>>>>>>> value add that would change some of the No's into Yes's.
>>>>>>> Sure.
>>>>>>>
>>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>>> I'd have to review the chapter, I don't really claim to be any Blueprint
>>>>>> expert...other than knowing it sucks... ;-)
>>>>>>
>>>>>> Of course if you were an expert you would know how much better it is than
>>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>>
>>>>> In fact, casual users wish for an almighty expert who knows all solutions
>>>>> in-depth and exposes them to all.
>>>>>
>>>>> If there's no such expert, the second best method is, experts of different
>>>>> solutions advertise themself and compare with each other.
>>>>>
>>>>> Maybe that can be called religious flame war, but it's valuable. What we
>>>>> really need in open community is simple and perfect product in technology,
>>>>> but not many repeat manufacturing wheels like some outside companies.
>>>>>
>>>>> Regards,
>>>>> drhades
>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Alasdair
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>>>>>> compare the features...perhaps I could re-create that table on a web
>>>>>> page...
>>>>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>>>>>> propagate to our static pages.
>>>>>>>>>
>>>>>>>>> Clement, please double check the iPOJO features, since you've added
>>>>>> features
>>>>>>>>> since the book has been published.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> drhades
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wonder what is the difference between these three component
>>>>>> runtime.
>>>>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
>>>>>> more
>>>>>>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I guess everyone like myself is seeing this question occur regularly
>>>>>> on
>>>>>>>>>>>> this
>>>>>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>>>>>> wiki/web
>>>>>>>>>>>> page to with the pros and cons.
>>>>>>>>>>>>
>>>>>>>>>>>> I myself have many questions and can't really tell which is best for
>>>>>> our
>>>>>>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>>>>>> configuration information needed to wire the server inside a
>>>>>> LDIF/LDAP
>>>>>>>>>>>> based
>>>>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>>>>
>>>>>>>>>>>> Excuse the digression on our specific issues but regarding having a
>>>>>> page
>>>>>>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>>>>>> many
>>>>>>>>>>>> of
>>>>>>>>>>>> our users.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Alex
>>>>>>>>>>>>
Re: iPOJO vs SCR vs Blueprint
Posted by Peter Kriens <pe...@aqute.biz>.
Obviously everybody needs all these goodies you mention. However the choice is to do this in iPOJO with a new "language" and new semantics attached to it or do it in Java. I am very familiar with the semantics of Java and the pain of the redundancy in Java over iPOJO in this area has not been high enough to make this switch seem desirable.
Kind regards,
Peter Kriens
On 8 jun 2011, at 15:24, Richard S. Hall wrote:
> On 6/8/11 9:13, Peter Kriens wrote:
>> The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features.
>>
>> In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch.
>
> Yeah, who needs things like automatic concurrency handling for services or byte-code generated smart service references that eliminate the need to turn everything into a component in order to pass around services throughout your component? It's better to do all that stuff by hand with DS... ;-)
>
> -> richard
>
> p.s. Sorry, I couldn't resist... :-P
>
>> Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> Just stating an incompletely informed opinion here ..
>>>
>>> If you want something simple, light-weight and easy to use, go for
>>> Declarative Services.
>>>
>>> If you want elaborate functionality or need something Declarative
>>> Services does not provide, consider iPojo (I understand it is an
>>> evolution of Declarative Services, right ?)
>>>
>>> If you have a Spring background go for blueprint.
>>>
>>> Regards
>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>
>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham<no...@apache.org> wrote:
>>>>
>>>>>
>>>>> Alasdair Nottingham
>>>>>
>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<he...@ungoverned.org> wrote:
>>>>>
>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is good I might link to it, or pinch it for the aries webpage too
>>>>>>> if that is ok. When doing that thought I would put some changes into
>>>>>>> the blueprint column. The Aries blueprint implementation provides some
>>>>>>> value add that would change some of the No's into Yes's.
>>>>>> Sure.
>>>>>>
>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>> I'd have to review the chapter, I don't really claim to be any Blueprint
>>>>> expert...other than knowing it sucks... ;-)
>>>>>
>>>>> Of course if you were an expert you would know how much better it is than
>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>
>>>> In fact, casual users wish for an almighty expert who knows all solutions
>>>> in-depth and exposes them to all.
>>>>
>>>> If there's no such expert, the second best method is, experts of different
>>>> solutions advertise themself and compare with each other.
>>>>
>>>> Maybe that can be called religious flame war, but it's valuable. What we
>>>> really need in open community is simple and perfect product in technology,
>>>> but not many repeat manufacturing wheels like some outside companies.
>>>>
>>>> Regards,
>>>> drhades
>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> Thanks
>>>>>>> Alasdair
>>>>>>>
>>>>>>>
>>>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>>>>> compare the features...perhaps I could re-create that table on a web
>>>>> page...
>>>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>>>>> propagate to our static pages.
>>>>>>>>
>>>>>>>> Clement, please double check the iPOJO features, since you've added
>>>>> features
>>>>>>>> since the book has been published.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> drhades
>>>>>>>>>>
>>>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>>> heavy@ungoverned.org
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder what is the difference between these three component
>>>>> runtime.
>>>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
>>>>> more
>>>>>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I guess everyone like myself is seeing this question occur regularly
>>>>> on
>>>>>>>>>>> this
>>>>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>>>>> wiki/web
>>>>>>>>>>> page to with the pros and cons.
>>>>>>>>>>>
>>>>>>>>>>> I myself have many questions and can't really tell which is best for
>>>>> our
>>>>>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>>>>> configuration information needed to wire the server inside a
>>>>> LDIF/LDAP
>>>>>>>>>>> based
>>>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>>>
>>>>>>>>>>> Excuse the digression on our specific issues but regarding having a
>>>>> page
>>>>>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>>>>> many
>>>>>>>>>>> of
>>>>>>>>>>> our users.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>
>>>
Re: iPOJO vs SCR vs Blueprint
Posted by Peter Kriens <pe...@aqute.biz>.
I guess you'd rather have someone write your app as well? :-)
The beauty of it all is that you you could actually write your perfect manager and it would work seamlessly with all the others.
Kind regards,
Peter Kriens
On 10 jun 2011, at 22:27, Andrei Pozolotin wrote:
> in my experience:
> 1) blueprint is a disaster
> 2) ipojo is over-kill
> 3) ds is under-kill :-)
> and yes, I would like to see some features of ipojo in scr
>
> -------- Original Message --------
> Subject: Re: iPOJO vs SCR vs Blueprint
> From: Richard S. Hall <he...@ungoverned.org>
> To: dev@felix.apache.org
> Date: Wed 08 Jun 2011 08:24:02 AM CDT
>> On 6/8/11 9:13, Peter Kriens wrote:
>>> The summary for me is that DS is limited to simplifying being a
>>> service and depending on other services while iPOJO and Blueprint add
>>> a programming language (XML/Annotations) that support services among
>>> many, many other features.
>>>
>>> In my experience DS is the simplest and least intrusive, especially
>>> with the SCR or bnd annotations. Blueprint is not my favorite because
>>> I consider XML among the worst programming languages one can imagine.
>>> I do not have a lot of experience with iPOJO; it is clearly the most
>>> powerful but it somehow lacks a compelling reason to switch as none
>>> of its additional functions seem worth the effort to switch.
>>
>> Yeah, who needs things like automatic concurrency handling for
>> services or byte-code generated smart service references that
>> eliminate the need to turn everything into a component in order to
>> pass around services throughout your component? It's better to do all
>> that stuff by hand with DS... ;-)
>>
>> -> richard
>>
>> p.s. Sorry, I couldn't resist... :-P
>>
>>> Anyway, who cares. They all interact very nicely and switching from
>>> one to the other is not so hard as long as you could in POJOs.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> Just stating an incompletely informed opinion here ..
>>>>
>>>> If you want something simple, light-weight and easy to use, go for
>>>> Declarative Services.
>>>>
>>>> If you want elaborate functionality or need something Declarative
>>>> Services does not provide, consider iPojo (I understand it is an
>>>> evolution of Declarative Services, right ?)
>>>>
>>>> If you have a Spring background go for blueprint.
>>>>
>>>> Regards
>>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>>
>>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair
>>>>> Nottingham<no...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> Alasdair Nottingham
>>>>>>
>>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<he...@ungoverned.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is good I might link to it, or pinch it for the aries
>>>>>>>> webpage too
>>>>>>>> if that is ok. When doing that thought I would put some changes
>>>>>>>> into
>>>>>>>> the blueprint column. The Aries blueprint implementation
>>>>>>>> provides some
>>>>>>>> value add that would change some of the No's into Yes's.
>>>>>>> Sure.
>>>>>>>
>>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>>> I'd have to review the chapter, I don't really claim to be any
>>>>>>> Blueprint
>>>>>> expert...other than knowing it sucks... ;-)
>>>>>>
>>>>>> Of course if you were an expert you would know how much better it
>>>>>> is than
>>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>>
>>>>> In fact, casual users wish for an almighty expert who knows all
>>>>> solutions
>>>>> in-depth and exposes them to all.
>>>>>
>>>>> If there's no such expert, the second best method is, experts of
>>>>> different
>>>>> solutions advertise themself and compare with each other.
>>>>>
>>>>> Maybe that can be called religious flame war, but it's valuable.
>>>>> What we
>>>>> really need in open community is simple and perfect product in
>>>>> technology,
>>>>> but not many repeat manufacturing wheels like some outside companies.
>>>>>
>>>>> Regards,
>>>>> drhades
>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Alasdair
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org>
>>>>>>>> wrote:
>>>>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>>>>> We actually have a table in our book (OSGi in Action) that
>>>>>>>>>> tries to
>>>>>>>>>> compare the features...perhaps I could re-create that table on
>>>>>>>>>> a web
>>>>>> page...
>>>>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>>
>>>>>>>>> It's not perfect, but it is better than nothing. It should
>>>>>>>>> eventually
>>>>>>>>> propagate to our static pages.
>>>>>>>>>
>>>>>>>>> Clement, please double check the iPOJO features, since you've
>>>>>>>>> added
>>>>>> features
>>>>>>>>> since the book has been published.
>>>>>>>>>
>>>>>>>>> -> richard
>>>>>>>>>
>>>>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> drhades
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex
>>>>>>>>>>> Karasulu<ak...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>>>> heavy@ungoverned.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wonder what is the difference between these three component
>>>>>> runtime.
>>>>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO
>>>>>>>>>>>>> provide
>>>>>> more
>>>>>>>>>>>>> sophisticated features than DS. Each has a different focus
>>>>>>>>>>>>> or goal.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I guess everyone like myself is seeing this question occur
>>>>>>>>>>>> regularly
>>>>>> on
>>>>>>>>>>>> this
>>>>>>>>>>>> mailing list. It's a valid question that perhaps we can
>>>>>>>>>>>> dedicate a
>>>>>>>>>>>> wiki/web
>>>>>>>>>>>> page to with the pros and cons.
>>>>>>>>>>>>
>>>>>>>>>>>> I myself have many questions and can't really tell which is
>>>>>>>>>>>> best for
>>>>>> our
>>>>>>>>>>>> needs at directory but I do know that I have to sit down and
>>>>>>>>>>>> do the
>>>>>>>>>>>> research. However our situation is much more unique since
>>>>>>>>>>>> we back
>>>>>>>>>>>> configuration information needed to wire the server inside a
>>>>>> LDIF/LDAP
>>>>>>>>>>>> based
>>>>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>>>>
>>>>>>>>>>>> Excuse the digression on our specific issues but regarding
>>>>>>>>>>>> having a
>>>>>> page
>>>>>>>>>>>> dedicated to the pros and cons of each option at felix could
>>>>>>>>>>>> benefit
>>>>>>>>>>>> many
>>>>>>>>>>>> of
>>>>>>>>>>>> our users.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Alex
>>>>>>>>>>>>
>>>>>>>>
>>>>
>>
>
Re: iPOJO vs SCR vs Blueprint
Posted by Andrei Pozolotin <an...@gmail.com>.
in my experience:
1) blueprint is a disaster
2) ipojo is over-kill
3) ds is under-kill :-)
and yes, I would like to see some features of ipojo in scr
-------- Original Message --------
Subject: Re: iPOJO vs SCR vs Blueprint
From: Richard S. Hall <he...@ungoverned.org>
To: dev@felix.apache.org
Date: Wed 08 Jun 2011 08:24:02 AM CDT
> On 6/8/11 9:13, Peter Kriens wrote:
>> The summary for me is that DS is limited to simplifying being a
>> service and depending on other services while iPOJO and Blueprint add
>> a programming language (XML/Annotations) that support services among
>> many, many other features.
>>
>> In my experience DS is the simplest and least intrusive, especially
>> with the SCR or bnd annotations. Blueprint is not my favorite because
>> I consider XML among the worst programming languages one can imagine.
>> I do not have a lot of experience with iPOJO; it is clearly the most
>> powerful but it somehow lacks a compelling reason to switch as none
>> of its additional functions seem worth the effort to switch.
>
> Yeah, who needs things like automatic concurrency handling for
> services or byte-code generated smart service references that
> eliminate the need to turn everything into a component in order to
> pass around services throughout your component? It's better to do all
> that stuff by hand with DS... ;-)
>
> -> richard
>
> p.s. Sorry, I couldn't resist... :-P
>
>> Anyway, who cares. They all interact very nicely and switching from
>> one to the other is not so hard as long as you could in POJOs.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> Just stating an incompletely informed opinion here ..
>>>
>>> If you want something simple, light-weight and easy to use, go for
>>> Declarative Services.
>>>
>>> If you want elaborate functionality or need something Declarative
>>> Services does not provide, consider iPojo (I understand it is an
>>> evolution of Declarative Services, right ?)
>>>
>>> If you have a Spring background go for blueprint.
>>>
>>> Regards
>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>
>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair
>>>> Nottingham<no...@apache.org> wrote:
>>>>
>>>>>
>>>>> Alasdair Nottingham
>>>>>
>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<he...@ungoverned.org>
>>>>> wrote:
>>>>>
>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is good I might link to it, or pinch it for the aries
>>>>>>> webpage too
>>>>>>> if that is ok. When doing that thought I would put some changes
>>>>>>> into
>>>>>>> the blueprint column. The Aries blueprint implementation
>>>>>>> provides some
>>>>>>> value add that would change some of the No's into Yes's.
>>>>>> Sure.
>>>>>>
>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>> I'd have to review the chapter, I don't really claim to be any
>>>>>> Blueprint
>>>>> expert...other than knowing it sucks... ;-)
>>>>>
>>>>> Of course if you were an expert you would know how much better it
>>>>> is than
>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>
>>>> In fact, casual users wish for an almighty expert who knows all
>>>> solutions
>>>> in-depth and exposes them to all.
>>>>
>>>> If there's no such expert, the second best method is, experts of
>>>> different
>>>> solutions advertise themself and compare with each other.
>>>>
>>>> Maybe that can be called religious flame war, but it's valuable.
>>>> What we
>>>> really need in open community is simple and perfect product in
>>>> technology,
>>>> but not many repeat manufacturing wheels like some outside companies.
>>>>
>>>> Regards,
>>>> drhades
>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> Thanks
>>>>>>> Alasdair
>>>>>>>
>>>>>>>
>>>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org>
>>>>>>> wrote:
>>>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>>>> We actually have a table in our book (OSGi in Action) that
>>>>>>>>> tries to
>>>>>>>>> compare the features...perhaps I could re-create that table on
>>>>>>>>> a web
>>>>> page...
>>>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>
>>>>>>>> It's not perfect, but it is better than nothing. It should
>>>>>>>> eventually
>>>>>>>> propagate to our static pages.
>>>>>>>>
>>>>>>>> Clement, please double check the iPOJO features, since you've
>>>>>>>> added
>>>>> features
>>>>>>>> since the book has been published.
>>>>>>>>
>>>>>>>> -> richard
>>>>>>>>
>>>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> drhades
>>>>>>>>>>
>>>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex
>>>>>>>>>> Karasulu<ak...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>>> heavy@ungoverned.org
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder what is the difference between these three component
>>>>> runtime.
>>>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO
>>>>>>>>>>>> provide
>>>>> more
>>>>>>>>>>>> sophisticated features than DS. Each has a different focus
>>>>>>>>>>>> or goal.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I guess everyone like myself is seeing this question occur
>>>>>>>>>>> regularly
>>>>> on
>>>>>>>>>>> this
>>>>>>>>>>> mailing list. It's a valid question that perhaps we can
>>>>>>>>>>> dedicate a
>>>>>>>>>>> wiki/web
>>>>>>>>>>> page to with the pros and cons.
>>>>>>>>>>>
>>>>>>>>>>> I myself have many questions and can't really tell which is
>>>>>>>>>>> best for
>>>>> our
>>>>>>>>>>> needs at directory but I do know that I have to sit down and
>>>>>>>>>>> do the
>>>>>>>>>>> research. However our situation is much more unique since
>>>>>>>>>>> we back
>>>>>>>>>>> configuration information needed to wire the server inside a
>>>>> LDIF/LDAP
>>>>>>>>>>> based
>>>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>>>
>>>>>>>>>>> Excuse the digression on our specific issues but regarding
>>>>>>>>>>> having a
>>>>> page
>>>>>>>>>>> dedicated to the pros and cons of each option at felix could
>>>>>>>>>>> benefit
>>>>>>>>>>> many
>>>>>>>>>>> of
>>>>>>>>>>> our users.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>
>>>
>
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/8/11 9:13, Peter Kriens wrote:
> The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features.
>
> In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch.
Yeah, who needs things like automatic concurrency handling for services
or byte-code generated smart service references that eliminate the need
to turn everything into a component in order to pass around services
throughout your component? It's better to do all that stuff by hand with
DS... ;-)
-> richard
p.s. Sorry, I couldn't resist... :-P
> Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>
>> Hi,
>>
>> Just stating an incompletely informed opinion here ..
>>
>> If you want something simple, light-weight and easy to use, go for
>> Declarative Services.
>>
>> If you want elaborate functionality or need something Declarative
>> Services does not provide, consider iPojo (I understand it is an
>> evolution of Declarative Services, right ?)
>>
>> If you have a Spring background go for blueprint.
>>
>> Regards
>> Felix, whose loves and sticks with Declarative Services ;-)
>>
>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham<no...@apache.org> wrote:
>>>
>>>>
>>>> Alasdair Nottingham
>>>>
>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<he...@ungoverned.org> wrote:
>>>>
>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This is good I might link to it, or pinch it for the aries webpage too
>>>>>> if that is ok. When doing that thought I would put some changes into
>>>>>> the blueprint column. The Aries blueprint implementation provides some
>>>>>> value add that would change some of the No's into Yes's.
>>>>> Sure.
>>>>>
>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>> down for blueprint I was wondering what you meant by this.
>>>>> I'd have to review the chapter, I don't really claim to be any Blueprint
>>>> expert...other than knowing it sucks... ;-)
>>>>
>>>> Of course if you were an expert you would know how much better it is than
>>>> anything else ;) let the religious flame war begin, or not.
>>>>
>>> In fact, casual users wish for an almighty expert who knows all solutions
>>> in-depth and exposes them to all.
>>>
>>> If there's no such expert, the second best method is, experts of different
>>> solutions advertise themself and compare with each other.
>>>
>>> Maybe that can be called religious flame war, but it's valuable. What we
>>> really need in open community is simple and perfect product in technology,
>>> but not many repeat manufacturing wheels like some outside companies.
>>>
>>> Regards,
>>> drhades
>>>
>>>>> -> richard
>>>>>
>>>>>> Thanks
>>>>>> Alasdair
>>>>>>
>>>>>>
>>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>>>> compare the features...perhaps I could re-create that table on a web
>>>> page...
>>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>>
>>>>>>>
>>>>>>>
>>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>>>> propagate to our static pages.
>>>>>>>
>>>>>>> Clement, please double check the iPOJO features, since you've added
>>>> features
>>>>>>> since the book has been published.
>>>>>>>
>>>>>>> -> richard
>>>>>>>
>>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> drhades
>>>>>>>>>
>>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>>> heavy@ungoverned.org
>>>>>>>>>>> wrote:
>>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I wonder what is the difference between these three component
>>>> runtime.
>>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
>>>> more
>>>>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I guess everyone like myself is seeing this question occur regularly
>>>> on
>>>>>>>>>> this
>>>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>>>> wiki/web
>>>>>>>>>> page to with the pros and cons.
>>>>>>>>>>
>>>>>>>>>> I myself have many questions and can't really tell which is best for
>>>> our
>>>>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>>>> configuration information needed to wire the server inside a
>>>> LDIF/LDAP
>>>>>>>>>> based
>>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>>
>>>>>>>>>> Excuse the digression on our specific issues but regarding having a
>>>> page
>>>>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>>>> many
>>>>>>>>>> of
>>>>>>>>>> our users.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>
>>
Re: iPOJO vs SCR vs Blueprint
Posted by Peter Kriens <pe...@aqute.biz>.
The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features.
In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch.
Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs.
Kind regards,
Peter Kriens
On 30 mei 2011, at 13:25, Felix Meschberger wrote:
> Hi,
>
> Just stating an incompletely informed opinion here ..
>
> If you want something simple, light-weight and easy to use, go for
> Declarative Services.
>
> If you want elaborate functionality or need something Declarative
> Services does not provide, consider iPojo (I understand it is an
> evolution of Declarative Services, right ?)
>
> If you have a Spring background go for blueprint.
>
> Regards
> Felix, whose loves and sticks with Declarative Services ;-)
>
> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham <no...@apache.org> wrote:
>>
>>>
>>>
>>> Alasdair Nottingham
>>>
>>> On 25 May 2011, at 22:16, "Richard S. Hall" <he...@ungoverned.org> wrote:
>>>
>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>> Hi,
>>>>>
>>>>> This is good I might link to it, or pinch it for the aries webpage too
>>>>> if that is ok. When doing that thought I would put some changes into
>>>>> the blueprint column. The Aries blueprint implementation provides some
>>>>> value add that would change some of the No's into Yes's.
>>>>
>>>> Sure.
>>>>
>>>>> One thing though in component lifecycle control you have a Partial
>>>>> down for blueprint I was wondering what you meant by this.
>>>>
>>>> I'd have to review the chapter, I don't really claim to be any Blueprint
>>> expert...other than knowing it sucks... ;-)
>>>
>>> Of course if you were an expert you would know how much better it is than
>>> anything else ;) let the religious flame war begin, or not.
>>>
>>
>> In fact, casual users wish for an almighty expert who knows all solutions
>> in-depth and exposes them to all.
>>
>> If there's no such expert, the second best method is, experts of different
>> solutions advertise themself and compare with each other.
>>
>> Maybe that can be called religious flame war, but it's valuable. What we
>> really need in open community is simple and perfect product in technology,
>> but not many repeat manufacturing wheels like some outside companies.
>>
>> Regards,
>> drhades
>>
>>>
>>>>
>>>> -> richard
>>>>
>>>>> Thanks
>>>>> Alasdair
>>>>>
>>>>>
>>>>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>>>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>>>>> compare the features...perhaps I could re-create that table on a web
>>> page...
>>>>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>>>>
>>>>>>
>>>>>>
>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>>>>
>>>>>> It's not perfect, but it is better than nothing. It should eventually
>>>>>> propagate to our static pages.
>>>>>>
>>>>>> Clement, please double check the iPOJO features, since you've added
>>> features
>>>>>> since the book has been published.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> On 5/25/11 5:26, jie yan wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> drhades
>>>>>>>>
>>>>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
>>> heavy@ungoverned.org
>>>>>>>>>> wrote:
>>>>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>>>>
>>>>>>>>>>> I wonder what is the difference between these three component
>>> runtime.
>>>>>>>>>>>
>>>>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
>>> more
>>>>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I guess everyone like myself is seeing this question occur regularly
>>> on
>>>>>>>>> this
>>>>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>>>>> wiki/web
>>>>>>>>> page to with the pros and cons.
>>>>>>>>>
>>>>>>>>> I myself have many questions and can't really tell which is best for
>>> our
>>>>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>>>>> research. However our situation is much more unique since we back
>>>>>>>>> configuration information needed to wire the server inside a
>>> LDIF/LDAP
>>>>>>>>> based
>>>>>>>>> backing store. Lots to think about for us.
>>>>>>>>>
>>>>>>>>> Excuse the digression on our specific issues but regarding having a
>>> page
>>>>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>>>>> many
>>>>>>>>> of
>>>>>>>>> our users.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>
>>>>>
>>>
>
>
Re: iPOJO vs SCR vs Blueprint
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Just stating an incompletely informed opinion here ..
If you want something simple, light-weight and easy to use, go for
Declarative Services.
If you want elaborate functionality or need something Declarative
Services does not provide, consider iPojo (I understand it is an
evolution of Declarative Services, right ?)
If you have a Spring background go for blueprint.
Regards
Felix, whose loves and sticks with Declarative Services ;-)
Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham <no...@apache.org> wrote:
>
> >
> >
> > Alasdair Nottingham
> >
> > On 25 May 2011, at 22:16, "Richard S. Hall" <he...@ungoverned.org> wrote:
> >
> > > On 5/25/11 16:26, Alasdair Nottingham wrote:
> > >> Hi,
> > >>
> > >> This is good I might link to it, or pinch it for the aries webpage too
> > >> if that is ok. When doing that thought I would put some changes into
> > >> the blueprint column. The Aries blueprint implementation provides some
> > >> value add that would change some of the No's into Yes's.
> > >
> > > Sure.
> > >
> > >> One thing though in component lifecycle control you have a Partial
> > >> down for blueprint I was wondering what you meant by this.
> > >
> > > I'd have to review the chapter, I don't really claim to be any Blueprint
> > expert...other than knowing it sucks... ;-)
> >
> > Of course if you were an expert you would know how much better it is than
> > anything else ;) let the religious flame war begin, or not.
> >
>
> In fact, casual users wish for an almighty expert who knows all solutions
> in-depth and exposes them to all.
>
> If there's no such expert, the second best method is, experts of different
> solutions advertise themself and compare with each other.
>
> Maybe that can be called religious flame war, but it's valuable. What we
> really need in open community is simple and perfect product in technology,
> but not many repeat manufacturing wheels like some outside companies.
>
> Regards,
> drhades
>
> >
> > >
> > > -> richard
> > >
> > >> Thanks
> > >> Alasdair
> > >>
> > >>
> > >> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
> > >>> On 5/25/11 9:19, Richard S. Hall wrote:
> > >>>> We actually have a table in our book (OSGi in Action) that tries to
> > >>>> compare the features...perhaps I could re-create that table on a web
> > page...
> > >>> Ok, I added the table to the iPOJO FAQ on wiki:
> > >>>
> > >>>
> > >>>
> > https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
> > >>>
> > >>> It's not perfect, but it is better than nothing. It should eventually
> > >>> propagate to our static pages.
> > >>>
> > >>> Clement, please double check the iPOJO features, since you've added
> > features
> > >>> since the book has been published.
> > >>>
> > >>> -> richard
> > >>>
> > >>>> On 5/25/11 5:26, jie yan wrote:
> > >>>>> +1
> > >>>>>
> > >>>>> Regards,
> > >>>>> drhades
> > >>>>>
> > >>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
> > heavy@ungoverned.org
> > >>>>>>> wrote:
> > >>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
> > >>>>>>>
> > >>>>>>>> I wonder what is the difference between these three component
> > runtime.
> > >>>>>>>>
> > >>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
> > more
> > >>>>>>> sophisticated features than DS. Each has a different focus or goal.
> > >>>>>>>
> > >>>>>>>
> > >>>>>> I guess everyone like myself is seeing this question occur regularly
> > on
> > >>>>>> this
> > >>>>>> mailing list. It's a valid question that perhaps we can dedicate a
> > >>>>>> wiki/web
> > >>>>>> page to with the pros and cons.
> > >>>>>>
> > >>>>>> I myself have many questions and can't really tell which is best for
> > our
> > >>>>>> needs at directory but I do know that I have to sit down and do the
> > >>>>>> research. However our situation is much more unique since we back
> > >>>>>> configuration information needed to wire the server inside a
> > LDIF/LDAP
> > >>>>>> based
> > >>>>>> backing store. Lots to think about for us.
> > >>>>>>
> > >>>>>> Excuse the digression on our specific issues but regarding having a
> > page
> > >>>>>> dedicated to the pros and cons of each option at felix could benefit
> > >>>>>> many
> > >>>>>> of
> > >>>>>> our users.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Alex
> > >>>>>>
> > >>
> > >>
> >
Re: iPOJO vs SCR vs Blueprint
Posted by jie yan <ya...@gmail.com>.
On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham <no...@apache.org> wrote:
>
>
> Alasdair Nottingham
>
> On 25 May 2011, at 22:16, "Richard S. Hall" <he...@ungoverned.org> wrote:
>
> > On 5/25/11 16:26, Alasdair Nottingham wrote:
> >> Hi,
> >>
> >> This is good I might link to it, or pinch it for the aries webpage too
> >> if that is ok. When doing that thought I would put some changes into
> >> the blueprint column. The Aries blueprint implementation provides some
> >> value add that would change some of the No's into Yes's.
> >
> > Sure.
> >
> >> One thing though in component lifecycle control you have a Partial
> >> down for blueprint I was wondering what you meant by this.
> >
> > I'd have to review the chapter, I don't really claim to be any Blueprint
> expert...other than knowing it sucks... ;-)
>
> Of course if you were an expert you would know how much better it is than
> anything else ;) let the religious flame war begin, or not.
>
In fact, casual users wish for an almighty expert who knows all solutions
in-depth and exposes them to all.
If there's no such expert, the second best method is, experts of different
solutions advertise themself and compare with each other.
Maybe that can be called religious flame war, but it's valuable. What we
really need in open community is simple and perfect product in technology,
but not many repeat manufacturing wheels like some outside companies.
Regards,
drhades
>
> >
> > -> richard
> >
> >> Thanks
> >> Alasdair
> >>
> >>
> >> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
> >>> On 5/25/11 9:19, Richard S. Hall wrote:
> >>>> We actually have a table in our book (OSGi in Action) that tries to
> >>>> compare the features...perhaps I could re-create that table on a web
> page...
> >>> Ok, I added the table to the iPOJO FAQ on wiki:
> >>>
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
> >>>
> >>> It's not perfect, but it is better than nothing. It should eventually
> >>> propagate to our static pages.
> >>>
> >>> Clement, please double check the iPOJO features, since you've added
> features
> >>> since the book has been published.
> >>>
> >>> -> richard
> >>>
> >>>> On 5/25/11 5:26, jie yan wrote:
> >>>>> +1
> >>>>>
> >>>>> Regards,
> >>>>> drhades
> >>>>>
> >>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<
> heavy@ungoverned.org
> >>>>>>> wrote:
> >>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
> >>>>>>>
> >>>>>>>> I wonder what is the difference between these three component
> runtime.
> >>>>>>>>
> >>>>>>> They all manage service dependencies. Blueprint and iPOJO provide
> more
> >>>>>>> sophisticated features than DS. Each has a different focus or goal.
> >>>>>>>
> >>>>>>>
> >>>>>> I guess everyone like myself is seeing this question occur regularly
> on
> >>>>>> this
> >>>>>> mailing list. It's a valid question that perhaps we can dedicate a
> >>>>>> wiki/web
> >>>>>> page to with the pros and cons.
> >>>>>>
> >>>>>> I myself have many questions and can't really tell which is best for
> our
> >>>>>> needs at directory but I do know that I have to sit down and do the
> >>>>>> research. However our situation is much more unique since we back
> >>>>>> configuration information needed to wire the server inside a
> LDIF/LDAP
> >>>>>> based
> >>>>>> backing store. Lots to think about for us.
> >>>>>>
> >>>>>> Excuse the digression on our specific issues but regarding having a
> page
> >>>>>> dedicated to the pros and cons of each option at felix could benefit
> >>>>>> many
> >>>>>> of
> >>>>>> our users.
> >>>>>>
> >>>>>> Best,
> >>>>>> Alex
> >>>>>>
> >>
> >>
>
Re: iPOJO vs SCR vs Blueprint
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair Nottingham
On 25 May 2011, at 22:16, "Richard S. Hall" <he...@ungoverned.org> wrote:
> On 5/25/11 16:26, Alasdair Nottingham wrote:
>> Hi,
>>
>> This is good I might link to it, or pinch it for the aries webpage too
>> if that is ok. When doing that thought I would put some changes into
>> the blueprint column. The Aries blueprint implementation provides some
>> value add that would change some of the No's into Yes's.
>
> Sure.
>
>> One thing though in component lifecycle control you have a Partial
>> down for blueprint I was wondering what you meant by this.
>
> I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-)
Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not.
>
> -> richard
>
>> Thanks
>> Alasdair
>>
>>
>> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>>> On 5/25/11 9:19, Richard S. Hall wrote:
>>>> We actually have a table in our book (OSGi in Action) that tries to
>>>> compare the features...perhaps I could re-create that table on a web page...
>>> Ok, I added the table to the iPOJO FAQ on wiki:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>>
>>> It's not perfect, but it is better than nothing. It should eventually
>>> propagate to our static pages.
>>>
>>> Clement, please double check the iPOJO features, since you've added features
>>> since the book has been published.
>>>
>>> -> richard
>>>
>>>> On 5/25/11 5:26, jie yan wrote:
>>>>> +1
>>>>>
>>>>> Regards,
>>>>> drhades
>>>>>
>>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>>>>> wrote:
>>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>>
>>>>>>>> I wonder what is the difference between these three component runtime.
>>>>>>>>
>>>>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>>
>>>>>>>
>>>>>> I guess everyone like myself is seeing this question occur regularly on
>>>>>> this
>>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>>> wiki/web
>>>>>> page to with the pros and cons.
>>>>>>
>>>>>> I myself have many questions and can't really tell which is best for our
>>>>>> needs at directory but I do know that I have to sit down and do the
>>>>>> research. However our situation is much more unique since we back
>>>>>> configuration information needed to wire the server inside a LDIF/LDAP
>>>>>> based
>>>>>> backing store. Lots to think about for us.
>>>>>>
>>>>>> Excuse the digression on our specific issues but regarding having a page
>>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>>> many
>>>>>> of
>>>>>> our users.
>>>>>>
>>>>>> Best,
>>>>>> Alex
>>>>>>
>>
>>
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/25/11 16:26, Alasdair Nottingham wrote:
> Hi,
>
> This is good I might link to it, or pinch it for the aries webpage too
> if that is ok. When doing that thought I would put some changes into
> the blueprint column. The Aries blueprint implementation provides some
> value add that would change some of the No's into Yes's.
Sure.
> One thing though in component lifecycle control you have a Partial
> down for blueprint I was wondering what you meant by this.
I'd have to review the chapter, I don't really claim to be any Blueprint
expert...other than knowing it sucks... ;-)
-> richard
> Thanks
> Alasdair
>
>
> On 25 May 2011 15:29, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 5/25/11 9:19, Richard S. Hall wrote:
>>> We actually have a table in our book (OSGi in Action) that tries to
>>> compare the features...perhaps I could re-create that table on a web page...
>> Ok, I added the table to the iPOJO FAQ on wiki:
>>
>>
>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>>
>> It's not perfect, but it is better than nothing. It should eventually
>> propagate to our static pages.
>>
>> Clement, please double check the iPOJO features, since you've added features
>> since the book has been published.
>>
>> -> richard
>>
>>> On 5/25/11 5:26, jie yan wrote:
>>>> +1
>>>>
>>>> Regards,
>>>> drhades
>>>>
>>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>>> wrote:
>>>>
>>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>>>> wrote:
>>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>>
>>>>>>> I wonder what is the difference between these three component runtime.
>>>>>>>
>>>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>>
>>>>>>
>>>>> I guess everyone like myself is seeing this question occur regularly on
>>>>> this
>>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>>> wiki/web
>>>>> page to with the pros and cons.
>>>>>
>>>>> I myself have many questions and can't really tell which is best for our
>>>>> needs at directory but I do know that I have to sit down and do the
>>>>> research. However our situation is much more unique since we back
>>>>> configuration information needed to wire the server inside a LDIF/LDAP
>>>>> based
>>>>> backing store. Lots to think about for us.
>>>>>
>>>>> Excuse the digression on our specific issues but regarding having a page
>>>>> dedicated to the pros and cons of each option at felix could benefit
>>>>> many
>>>>> of
>>>>> our users.
>>>>>
>>>>> Best,
>>>>> Alex
>>>>>
>
>
Re: iPOJO vs SCR vs Blueprint
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
This is good I might link to it, or pinch it for the aries webpage too
if that is ok. When doing that thought I would put some changes into
the blueprint column. The Aries blueprint implementation provides some
value add that would change some of the No's into Yes's.
One thing though in component lifecycle control you have a Partial
down for blueprint I was wondering what you meant by this.
Thanks
Alasdair
On 25 May 2011 15:29, Richard S. Hall <he...@ungoverned.org> wrote:
> On 5/25/11 9:19, Richard S. Hall wrote:
>>
>> We actually have a table in our book (OSGi in Action) that tries to
>> compare the features...perhaps I could re-create that table on a web page...
>
> Ok, I added the table to the iPOJO FAQ on wiki:
>
>
> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
>
> It's not perfect, but it is better than nothing. It should eventually
> propagate to our static pages.
>
> Clement, please double check the iPOJO features, since you've added features
> since the book has been published.
>
> -> richard
>
>> On 5/25/11 5:26, jie yan wrote:
>>>
>>> +1
>>>
>>> Regards,
>>> drhades
>>>
>>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>>> wrote:
>>>
>>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>>>
>>>>> wrote:
>>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>>
>>>>>> I wonder what is the difference between these three component runtime.
>>>>>>
>>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>>
>>>>>
>>>> I guess everyone like myself is seeing this question occur regularly on
>>>> this
>>>> mailing list. It's a valid question that perhaps we can dedicate a
>>>> wiki/web
>>>> page to with the pros and cons.
>>>>
>>>> I myself have many questions and can't really tell which is best for our
>>>> needs at directory but I do know that I have to sit down and do the
>>>> research. However our situation is much more unique since we back
>>>> configuration information needed to wire the server inside a LDIF/LDAP
>>>> based
>>>> backing store. Lots to think about for us.
>>>>
>>>> Excuse the digression on our specific issues but regarding having a page
>>>> dedicated to the pros and cons of each option at felix could benefit
>>>> many
>>>> of
>>>> our users.
>>>>
>>>> Best,
>>>> Alex
>>>>
>
--
Alasdair Nottingham
not@apache.org
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/25/11 9:19, Richard S. Hall wrote:
> We actually have a table in our book (OSGi in Action) that tries to
> compare the features...perhaps I could re-create that table on a web
> page...
Ok, I added the table to the iPOJO FAQ on wiki:
https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F
It's not perfect, but it is better than nothing. It should eventually
propagate to our static pages.
Clement, please double check the iPOJO features, since you've added
features since the book has been published.
-> richard
> On 5/25/11 5:26, jie yan wrote:
>> +1
>>
>> Regards,
>> drhades
>>
>> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org>
>> wrote:
>>
>>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>>> wrote:
>>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>>
>>>>> I wonder what is the difference between these three component
>>>>> runtime.
>>>>>
>>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>>> sophisticated features than DS. Each has a different focus or goal.
>>>>
>>>>
>>> I guess everyone like myself is seeing this question occur regularly on
>>> this
>>> mailing list. It's a valid question that perhaps we can dedicate a
>>> wiki/web
>>> page to with the pros and cons.
>>>
>>> I myself have many questions and can't really tell which is best for
>>> our
>>> needs at directory but I do know that I have to sit down and do the
>>> research. However our situation is much more unique since we back
>>> configuration information needed to wire the server inside a LDIF/LDAP
>>> based
>>> backing store. Lots to think about for us.
>>>
>>> Excuse the digression on our specific issues but regarding having a
>>> page
>>> dedicated to the pros and cons of each option at felix could benefit
>>> many
>>> of
>>> our users.
>>>
>>> Best,
>>> Alex
>>>
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
We actually have a table in our book (OSGi in Action) that tries to
compare the features...perhaps I could re-create that table on a web page...
-> richard
On 5/25/11 5:26, jie yan wrote:
> +1
>
> Regards,
> drhades
>
> On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu<ak...@apache.org> wrote:
>
>> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall<heavy@ungoverned.org
>>> wrote:
>>> On 05/24/2011 09:46 PM, jie yan wrote:
>>>
>>>> I wonder what is the difference between these three component runtime.
>>>>
>>> They all manage service dependencies. Blueprint and iPOJO provide more
>>> sophisticated features than DS. Each has a different focus or goal.
>>>
>>>
>> I guess everyone like myself is seeing this question occur regularly on
>> this
>> mailing list. It's a valid question that perhaps we can dedicate a wiki/web
>> page to with the pros and cons.
>>
>> I myself have many questions and can't really tell which is best for our
>> needs at directory but I do know that I have to sit down and do the
>> research. However our situation is much more unique since we back
>> configuration information needed to wire the server inside a LDIF/LDAP
>> based
>> backing store. Lots to think about for us.
>>
>> Excuse the digression on our specific issues but regarding having a page
>> dedicated to the pros and cons of each option at felix could benefit many
>> of
>> our users.
>>
>> Best,
>> Alex
>>
Re: iPOJO vs SCR vs Blueprint
Posted by jie yan <ya...@gmail.com>.
+1
Regards,
drhades
On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu <ak...@apache.org> wrote:
> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
>
> > On 05/24/2011 09:46 PM, jie yan wrote:
> >
> >> I wonder what is the difference between these three component runtime.
> >>
> >
> > They all manage service dependencies. Blueprint and iPOJO provide more
> > sophisticated features than DS. Each has a different focus or goal.
> >
> >
> I guess everyone like myself is seeing this question occur regularly on
> this
> mailing list. It's a valid question that perhaps we can dedicate a wiki/web
> page to with the pros and cons.
>
> I myself have many questions and can't really tell which is best for our
> needs at directory but I do know that I have to sit down and do the
> research. However our situation is much more unique since we back
> configuration information needed to wire the server inside a LDIF/LDAP
> based
> backing store. Lots to think about for us.
>
> Excuse the digression on our specific issues but regarding having a page
> dedicated to the pros and cons of each option at felix could benefit many
> of
> our users.
>
> Best,
> Alex
>
Re: iPOJO vs SCR vs Blueprint
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 05/24/2011 09:46 PM, jie yan wrote:
>
>> I wonder what is the difference between these three component runtime.
>>
>
> They all manage service dependencies. Blueprint and iPOJO provide more
> sophisticated features than DS. Each has a different focus or goal.
>
>
I guess everyone like myself is seeing this question occur regularly on this
mailing list. It's a valid question that perhaps we can dedicate a wiki/web
page to with the pros and cons.
I myself have many questions and can't really tell which is best for our
needs at directory but I do know that I have to sit down and do the
research. However our situation is much more unique since we back
configuration information needed to wire the server inside a LDIF/LDAP based
backing store. Lots to think about for us.
Excuse the digression on our specific issues but regarding having a page
dedicated to the pros and cons of each option at felix could benefit many of
our users.
Best,
Alex
Re: iPOJO vs SCR vs Blueprint
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 05/24/2011 09:46 PM, jie yan wrote:
> I wonder what is the difference between these three component runtime.
They all manage service dependencies. Blueprint and iPOJO provide more
sophisticated features than DS. Each has a different focus or goal.
> Is there the best one which can take over the others, then we could focus
> attention on just one solution?
The best one just depends on your needs. You need to look at the
features each provide and decide which features you need. All three can
work together via the service registry, so you don't have to worry about
making one decision for all time.
-> richard
> Regards,
> drhades
>