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<[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]
