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<n...@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<akaras...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>> >>> >
