[This was going to be a response to the DS vs Blueprint thread.. but got too long]
Re: DS vs Blueprint? What about complex concerns like providing aop on thousands of services? Speaking to David Bosschaert briefly about this at osgi con, he suggested two options, service interception (via service listener I believe) and/or asm/weaving/etc (David correct me if I'm wrong here). Which of DS or Blueprint lends itself better with these concerns? It would seem to me that DS lends itself better when development is on "new" components while Blueprint seems more "integrate-able" with already established, non-osgi, components. This brings me to my main topic and a comment I have after all the fantastic talks from the convention is that the vast majority of application of osgi (except of course for Graham's talk exploring the history of Websphere's evolution to osgi) seems focused on new development. Meanwhile it's evident that a key osgi value for many ( again demonstrated by both the websphere and eclipse cases) is in taking a complex system and migrating it to a modular architecture and osgi. I think this is where a lot of developers hit a wall. We can't just start from scratch. Secondly, by nature of having arrived at the osgi "conclusion", the issue was quite obviously that complexity already existed. At the OSGi BoF, it was asked "what could the osgi community do to help make it easier for new developers". It would be extremely valuable to have several demonstrations of taking some non-osgi application containing at least some degree of complexity and transforming that to an osgi-ified one with insight into the decisions and best practices. i.e. o(sgi)petstore is fine and dandy, there are plenty of those (Tim Ward demonstrated ~120) but what I really would benefit from is a jpetstore -> opetstore migration. In an effort to make some of that experience available to the general public, David also suggested that it would be great for Liferay to publish it's experience, and so I think I may do just that. The caveat being of course that as "new" osgi-ers we will likely show that we made some wrong decisions. However, I feel emboldened by Graham's admittance of IBM having made mistakes along the road. If IBM can do that, surely we can do that too. It was a great pleasure meeting many of you. Sincerely, Ray
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
