t; 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
> To: dev@
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
To: dev@felix.apache.org
Date: Wed 08 Jun 2011 08
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,
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 hi
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
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, especial
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 Decla
On Thu, May 26, 2011 at 10:38 AM, Richard S. Hall 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
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 a
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 leave
On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham wrote:
>
>
> Alasdair Nottingham
>
> On 25 May 2011, at 22: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 i
Alasdair Nottingham
On 25 May 2011, at 22: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 co
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
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
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 compo
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
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 wrote:
On Wed, May 25, 2011 at 6:2
+1
Regards,
drhades
On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu wrote:
> On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall >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
On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall 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 di
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
20 matches
Mail list logo
