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<[email protected]> 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<[email protected]> > 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 <[email protected]> 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<[email protected]> >>> 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 <[email protected]> >>> 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<[email protected]> >>> >> 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: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
