Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of andrei.pozolotin@gmail.com
 designates 209.85.210.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type;
        b=AA3iqV8bqpFiyKOhDgHpDiWFaHOwmsgdkBiMK1gbQVColazdYA3/1nCKFCyhvJ2AvW
         D7kUVKcyyj3u0bdW6pp8Om8Z7HTFC09yNwGgiLE+2HRSoZOB7tNu2N0WeKwU8UlirpzZ
         LeUbiN4HhlCh6O+iGK7DCbKG9wejwNjBomaoI=
Message-ID: <4DF27E3B.6090703@gmail.com>
Date: Fri, 10 Jun 2011 15:27:39 -0500
From: Andrei Pozolotin <andrei.pozolotin@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100228)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: iPOJO vs SCR vs Blueprint
References: <BANLkTikCKOG+aEnQmwgtX0_jP76RwWjDXw@mail.gmail.com>
 <4DDC776D.3060005@ungoverned.org>
 <BANLkTimKtRrk_QDUyRJvLQN1+3AQDBxs9g@mail.gmail.com>
 <BANLkTikZDC7ri99__sEHMeAboYQTqv7RjQ@mail.gmail.com>
 <4DDD01E9.6060705@ungoverned.org>	<4DDD124A.5030408@ungoverned.org>
 <BANLkTikNhzCsAD5AbrRtp-P65XxQNnaoow@mail.gmail.com>
 <4DDD71C1.3030707@ungoverned.org>
 <5BC9ADAA-1690-495B-94D2-9210121E30D2@apache.org>
 <BANLkTi=1ynVCHp+xnOdLYhLMJffj-kZ_5A@mail.gmail.com>
 <1306754731.20414.143.camel@meschbix>
 <621E75A3-C6DF-484D-93FE-2473E967A338@aQute.biz>
 <4DEF77F2.8030600@ungoverned.org>
In-Reply-To: <4DEF77F2.8030600@ungoverned.org>
Content-Type: multipart/alternative;
 boundary="------------090506050102000000040703"

--------------090506050102000000040703
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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


--------------090506050102000000040703--