« Return to Thread: iPojo and Blueprint
Re: iPojo and Blueprint
by Todor Boev
::
Rate this Message:
Charles Moulliard wrote:
> Neil,
>
> Thanks for the clarification. The idea that I promote behind my reply is not
> at all to debate which approach is better than the other but instead to make
> aware the opensource community that too much frameworks kill our
> goals/intents. The merit of EJB specification has been to become a standard
> used by all the actors (developer, architect, manufacturer of application
> server, ...) even if, from a technical point of view, EJB 1 and 2 have
> increased development life cycle. This is why Spring has taken the lead by
> promoting an easiest way to design enterprise solutions.
>
> For the future of the OSGI development based on SOA architecture or Service
> Component, we need to have strong/federating standards who will simplify our
> way to design/develop enterprise solutions. From my point of view, Blueprint
> is one of them and it should be interesting that existing frameworks align
> with this specification (like Spring DM will do soon).
>
Blueprint is derived from Spring DM so naturally Spring will migrate to the next
incarnation of their own standard. All of the other frameworks have critical
differences with Blueprint and for a good reason - there is still no one true
way (TM) to do component development with OSGi. I find somewhat sad the way
Blueprint threatens to suck out all creativity from this field because of the
desire of enterprise people to quickly get their EJB's or Spring Beans
reincarnated on top of OSGi.
Cheers,
Todor
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
>
> On Thu, Jul 2, 2009 at 1:21 PM, Neil Bartlett <njbartlett@...> wrote:
>
>> Charles,
>>
>> Of course iPOJO and Blueprint are compatible!
>>
>> Services exported by a bundle using iPOJO can be imported by a bundle
>> using Blueprint, and vice versa. All of these component models --
>> iPOJO, Blueprint, DS, Spring-DM, Peaberry etc -- interoperate
>> perfectly at the level of OSGi services. Of course they are all
>> implemented in different ways internally, but there is absolutely no
>> need to force every component model to implement Blueprint.
>>
>> Regards
>> Neil
>>
>> On Thu, Jul 2, 2009 at 12:12 PM, Charles Moulliard<cmoulliard@...>
>> wrote:
>>> If iPojo and Blueprint are not compatible. What can we do !
>>> This kind of situation is always frustrating for developers/designers and
>>> architects because choice must be done between competitors (Spring DM,
>>> Blueprint, iPojo, SCA, ...).
>>> Our time is precious. This is why having standards in OSG is really
>>> important like it is in Java World for J2EE specifications. I'm pretty
>> sure
>>> that this kind of situation will not help to promote OSGI as alternative
>> to
>>> classical development done on J2EE application servers like Websphere,
>> ...
>>> Regards,
>>>
>>> Charles Moulliard
>>> Senior Enterprise Architect
>>> Apache Camel Committer
>>>
>>> *****************************
>>> blog : http://cmoulliard.blogspot.com
>>>
>>>
>>> On Thu, Jul 2, 2009 at 11:59 AM, Guillaume Nodet <gnodet@...>
>> wrote:
>>>> When I first started the blueprint implementation, the idea was to use
>>>> iPojo and implement blueprint on top of it.
>>>> Unfortunately, iPojo and blueprint have very different ways of solving
>>>> the same problems, and it seems quite impossible to easily reconcile
>>>> those.
>>>> So, I don't think there will be any relationship between iPojo and
>>>> blueprint.
>>>>
>>>> On Thu, Jul 2, 2009 at 11:19, Charles Moulliard<cmoulliard@...>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> What are the future plans of iPojo regarding to OSGI specification (=
>> RFC
>>>>> 124 ) called Blueprint ? Will iPojo be migrated to be used as
>> blueprint
>>>>> services or iPojo will continue to live without integration with
>>>> blueprint ?
>>>>> Regards,
>>>>>
>>>>>
>>>>> Charles Moulliard
>>>>> Senior Enterprise Architect
>>>>> Apache Camel Committer
>>>>>
>>>>> *****************************
>>>>> blog : http://cmoulliard.blogspot.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
> Neil,
>
> Thanks for the clarification. The idea that I promote behind my reply is not
> at all to debate which approach is better than the other but instead to make
> aware the opensource community that too much frameworks kill our
> goals/intents. The merit of EJB specification has been to become a standard
> used by all the actors (developer, architect, manufacturer of application
> server, ...) even if, from a technical point of view, EJB 1 and 2 have
> increased development life cycle. This is why Spring has taken the lead by
> promoting an easiest way to design enterprise solutions.
>
> For the future of the OSGI development based on SOA architecture or Service
> Component, we need to have strong/federating standards who will simplify our
> way to design/develop enterprise solutions. From my point of view, Blueprint
> is one of them and it should be interesting that existing frameworks align
> with this specification (like Spring DM will do soon).
>
Blueprint is derived from Spring DM so naturally Spring will migrate to the next
incarnation of their own standard. All of the other frameworks have critical
differences with Blueprint and for a good reason - there is still no one true
way (TM) to do component development with OSGi. I find somewhat sad the way
Blueprint threatens to suck out all creativity from this field because of the
desire of enterprise people to quickly get their EJB's or Spring Beans
reincarnated on top of OSGi.
Cheers,
Todor
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
>
> On Thu, Jul 2, 2009 at 1:21 PM, Neil Bartlett <njbartlett@...> wrote:
>
>> Charles,
>>
>> Of course iPOJO and Blueprint are compatible!
>>
>> Services exported by a bundle using iPOJO can be imported by a bundle
>> using Blueprint, and vice versa. All of these component models --
>> iPOJO, Blueprint, DS, Spring-DM, Peaberry etc -- interoperate
>> perfectly at the level of OSGi services. Of course they are all
>> implemented in different ways internally, but there is absolutely no
>> need to force every component model to implement Blueprint.
>>
>> Regards
>> Neil
>>
>> On Thu, Jul 2, 2009 at 12:12 PM, Charles Moulliard<cmoulliard@...>
>> wrote:
>>> If iPojo and Blueprint are not compatible. What can we do !
>>> This kind of situation is always frustrating for developers/designers and
>>> architects because choice must be done between competitors (Spring DM,
>>> Blueprint, iPojo, SCA, ...).
>>> Our time is precious. This is why having standards in OSG is really
>>> important like it is in Java World for J2EE specifications. I'm pretty
>> sure
>>> that this kind of situation will not help to promote OSGI as alternative
>> to
>>> classical development done on J2EE application servers like Websphere,
>> ...
>>> Regards,
>>>
>>> Charles Moulliard
>>> Senior Enterprise Architect
>>> Apache Camel Committer
>>>
>>> *****************************
>>> blog : http://cmoulliard.blogspot.com
>>>
>>>
>>> On Thu, Jul 2, 2009 at 11:59 AM, Guillaume Nodet <gnodet@...>
>> wrote:
>>>> When I first started the blueprint implementation, the idea was to use
>>>> iPojo and implement blueprint on top of it.
>>>> Unfortunately, iPojo and blueprint have very different ways of solving
>>>> the same problems, and it seems quite impossible to easily reconcile
>>>> those.
>>>> So, I don't think there will be any relationship between iPojo and
>>>> blueprint.
>>>>
>>>> On Thu, Jul 2, 2009 at 11:19, Charles Moulliard<cmoulliard@...>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> What are the future plans of iPojo regarding to OSGI specification (=
>> RFC
>>>>> 124 ) called Blueprint ? Will iPojo be migrated to be used as
>> blueprint
>>>>> services or iPojo will continue to live without integration with
>>>> blueprint ?
>>>>> Regards,
>>>>>
>>>>>
>>>>> Charles Moulliard
>>>>> Senior Enterprise Architect
>>>>> Apache Camel Committer
>>>>>
>>>>> *****************************
>>>>> blog : http://cmoulliard.blogspot.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: iPojo and Blueprint
| Free embeddable forum powered by Nabble | Forum Help |
