felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Pozolotin <andrei.pozolo...@gmail.com>
Subject Re: iPOJO vs SCR vs Blueprint
Date Fri, 10 Jun 2011 20:27:39 GMT
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 <heavy@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<not@apache.org>  wrote:
>>>>
>>>>>
>>>>> Alasdair Nottingham
>>>>>
>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"<heavy@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<heavy@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
>>>>>>>>>>>
>>>>>>>
>>>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message