iPojo and Blueprint
|
View:
New views
16 Messages
—
Rating Filter:
Alert me
|
 |
iPojo and Blueprint
by cmoulliard
::
Rate this Message:
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 |
|
|
Re: iPojo and Blueprint
by gnodet
::
Rate this Message:
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@... |
|
|
Re: iPojo and Blueprint
by cmoulliard
::
Rate this Message:
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@... > > |
|
|
Re: iPojo and Blueprint
by gnodet
::
Rate this Message:
There are already two OSGi standards you can use:
* Declarative Services * Blueprint Note that spring-dm will implement blueprint very soon, so they won't be "competitors" anymore. But then, you have a lot of other things like iPojo, peaberry ... On Thu, Jul 2, 2009 at 13:12, 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@... >> >> > -- 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@... |
|
|
Re: iPojo and Blueprint
by Neil Bartlett
::
Rate this Message:
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@... |
|
|
Re: iPojo and Blueprint
by gnodet
::
Rate this Message:
Right, sorry if I was misunderstood.
All those technologies are compatible at the OSGi service registry level. My point was that it's not possible to *implement* blueprint using iPojo, that's all. On Thu, Jul 2, 2009 at 13:21, 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@... > > -- 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@... |
|
|
Re: iPojo and Blueprint
by Guillaume Sauthier
::
Rate this Message:
Yes iPOJO does not implement blueprint model, but remember that at the end, all components are exposed as OSGi services. That means that iPOJO and blueprint components are interoperables (you can mix them in your system). --Guillaume Charles Moulliard a écrit : > 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@... |
|
|
Re: iPojo and Blueprint
by cmoulliard
::
Rate this Message:
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). 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@... > > |
|
|
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@... |
|
|
Re: iPojo and Blueprint
by David Savage
::
Rate this Message:
Hmmm, I'm not so sure about this argument. I think it is useful to
differentiate between modularity specifications and component specifications in the same way we differentiate between vm specifications and languages specifications. .net and java both define virtual machine capabilities - the problem is that they are not interoperable at the binary layer. This is the risk with the OSGi/Jigsaw shenanigans. In terms of languages I think it has been accepted that many different languages can be compiled and interoperate in given virtual machine but this does not mean that one language is any "better" than another. Often the "best" language for an organisation is the one that allows them to define their process in the most succinct and maintainable way - where maintenance certainly includes availability of developers who understand the language - so here the common argument against DSL's certainly applies. I agree there is the risk of architectural complexity but just applying a lowest common denominator approach does not reduce this risk. Consider the complexity of some Java applications (in terms of numbers of classes, etc due to the language restrictions) compared with the simplicity of program written in a language such as Scala. I think the same is true for component specifications, the fact that iPojo is not compatible with Blueprint is not inherantly a /bad/ thing, just like Scala being different from Java, the issue is which is most appropriate for a given use case. Just some thoughts anyway, Regards, Dave blog: http://chronological-thought.blogspot.com web: http://www.paremus.com On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<cmoulliard@...> 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). > > 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@... |
|
|
Re: iPojo and Blueprint
by Neil Bartlett
::
Rate this Message:
Charles,
It was the evolution of Spring *outside* the EJB specifications that gave EJB the required impetus to improve. Likewise the existence of other component models outside of Blueprint and DS is useful to allow them to experiment with new ideas and potentially discover new approaches. In contrast to Spring, iPOJO arises from academic research into component models and has some very interesting and advanced features that cannot be implemented in Spring (but on the other hand it has some practical features which I dislike). Different applications need to make different trade offs and there is no sense forcing early standardisation of a still rapidly evolving area. The risk of multiple approaches is, of course, fragmentation. This is why the interoperability through OSGi services is so great -- we no longer need to choose between Spring or Guice or iPOJO etc and commit ourselves to that model exclusively until the end of time. In fact it becomes a per-bundle implementation detail. Far from fragmenting the space for components, OSGi services unify it. Neil On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<cmoulliard@...> 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). > > 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@... |
|
|
Re: iPojo and Blueprint
by Todor Boev
::
Rate this Message:
Neil Bartlett wrote: > Charles, > > It was the evolution of Spring *outside* the EJB specifications that > gave EJB the required impetus to improve. Likewise the existence of > other component models outside of Blueprint and DS is useful to allow > them to experiment with new ideas and potentially discover new > approaches. > > In contrast to Spring, iPOJO arises from academic research into > component models and has some very interesting and advanced features > that cannot be implemented in Spring (but on the other hand it has > some practical features which I dislike). Different applications need > to make different trade offs and there is no sense forcing early > standardisation of a still rapidly evolving area. > > The risk of multiple approaches is, of course, fragmentation. This is > why the interoperability through OSGi services is so great -- we no > longer need to choose between Spring or Guice or iPOJO etc and commit > ourselves to that model exclusively until the end of time. In fact it > becomes a per-bundle implementation detail. Far from fragmenting the > space for components, OSGi services unify it. > Amen to that Neil! :) > Neil > > On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<cmoulliard@...> 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). >> >> 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@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: iPojo and Blueprint
by Richard S. Hall
::
Rate this Message:
Charles,
While I can understand your desire to unify things, sometimes it just does not make sense and this is one of those times. The whole philosophy behind iPOJO is to embrace the dynamism and the service model inherent in OSGi and try to make it as easy as possible to develop with them. -> richard On 7/2/09 7:51 AM, 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). > > 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@... >> >> >> > > |
|
|
Re: iPojo and Blueprint
by Karl Pauls
::
Rate this Message:
On Thu, Jul 2, 2009 at 3:13 PM, Neil Bartlett<njbartlett@...> wrote:
> Charles, > > It was the evolution of Spring *outside* the EJB specifications that > gave EJB the required impetus to improve. Likewise the existence of > other component models outside of Blueprint and DS is useful to allow > them to experiment with new ideas and potentially discover new > approaches. > > In contrast to Spring, iPOJO arises from academic research into > component models and has some very interesting and advanced features > that cannot be implemented in Spring (but on the other hand it has > some practical features which I dislike). Different applications need > to make different trade offs and there is no sense forcing early > standardisation of a still rapidly evolving area. > > The risk of multiple approaches is, of course, fragmentation. This is > why the interoperability through OSGi services is so great -- we no > longer need to choose between Spring or Guice or iPOJO etc and commit > ourselves to that model exclusively until the end of time. In fact it > becomes a per-bundle implementation detail. In fact, it even becomes a per service implementation detail. At least in the cases where we are talking about service component models I don't think the bundle is the limit... > Far from fragmenting the space for components, OSGi services unify it. +1 regards, Karl > Neil > > On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<cmoulliard@...> 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). >> >> 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@... > > -- Karl Pauls karlpauls@... --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: iPojo and Blueprint
by gnodet
::
Rate this Message:
I agree with most what you said.
But when it comes to build an application, you can't really have your developers learn 3 different ways of doing the same thing, you kinda have to choose one and stick with it. I guess that's Charles' main concern here, because it's not about developping against *one* standard and eventually choose the implementation. You need to evaluate the different frameworks first. But I guess it's the same problem when building a web app, or even a jee app where you can choose between Spring or EJBs ... So that's far from a new story. On Thu, Jul 2, 2009 at 15:13, Neil Bartlett<njbartlett@...> wrote: > Charles, > > It was the evolution of Spring *outside* the EJB specifications that > gave EJB the required impetus to improve. Likewise the existence of > other component models outside of Blueprint and DS is useful to allow > them to experiment with new ideas and potentially discover new > approaches. > > In contrast to Spring, iPOJO arises from academic research into > component models and has some very interesting and advanced features > that cannot be implemented in Spring (but on the other hand it has > some practical features which I dislike). Different applications need > to make different trade offs and there is no sense forcing early > standardisation of a still rapidly evolving area. > > The risk of multiple approaches is, of course, fragmentation. This is > why the interoperability through OSGi services is so great -- we no > longer need to choose between Spring or Guice or iPOJO etc and commit > ourselves to that model exclusively until the end of time. In fact it > becomes a per-bundle implementation detail. Far from fragmenting the > space for components, OSGi services unify it. > > Neil > > On Thu, Jul 2, 2009 at 12:51 PM, Charles Moulliard<cmoulliard@...> 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). >> >> 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@... > > -- 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@... |
|
|
Re: iPojo and Blueprint
by Todor Boev
::
Rate this Message:
Guillaume Nodet wrote:
> I agree with most what you said. > But when it comes to build an application, you can't really have your > developers learn 3 different ways of doing the same thing, you kinda > have to choose one and stick with it. > I guess that's Charles' main concern here, because it's not about > developping against *one* standard and eventually choose the > implementation. You need to evaluate the different frameworks first. > But I guess it's the same problem when building a web app, or even a > jee app where you can choose between Spring or EJBs ... So that's far > from a new story. > Except with OSGi this does not have to be a final decision. You can convert your bundles from one framework to another one bundle at a time and still have your entire application running at every stage of this process. This shows how both the modular (side-by-side deployment) and the service (implementation independence) layers combine to give you unparalleled migration capability. In the end there is no free lunch - you have to change the code. But you get to do it at your own pace rather than as one huge swoop. I'm not deeply familiar with EJB's and Spring but I believe OSGi is the first environment to provide this power. I suspect newcomers to OSGi need some time to grasp the full consequences of having strong isolation at both levels: sharing classes (modular) and sharing instances (service). Throw into the mix dynamics at both layers and the subsequent need to let go of predictable startup/shutdown and the learning curve rockets upwards. Cheers, Todor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
