tag:blogger.com,1999:blog-34692233.post137116817455633907..comments2023-05-09T12:02:11.783+01:00Comments on Mind the Gap: Incremental OSGi with Virgo, Gemini, and LibraGlynhttp://www.blogger.com/profile/08741529390385812080noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-34692233.post-68251983609210555632011-03-21T17:41:56.103+00:002011-03-21T17:41:56.103+00:00Hi Dave
Doubtless some people prefer a revolution...Hi Dave<br /><br />Doubtless some people prefer a revolutionary approach.<br /><br />The evolutionary, incremental approach maximises reuse of existing skills and code, which I think appeals to more conservative developers, system administrators, etc.<br /><br />You point out an interesting trade-off in introducing Spring DM or Blueprint. With those technologies, you need to write a lot less low-level code and you get the usual dependency injection benefits such as looser coupling and easier unit testing. But yes, there is a cost in understanding the XML syntax. However I've not heard anyone really argue that the costs outweigh the benefits, if that's what you are saying.<br /><br />I'm most interested in your wish to get the lower-level OSGi house in order. What do you think the critical problems are?<br /><br />Regards,<br />GlynGlynhttps://www.blogger.com/profile/08741529390385812080noreply@blogger.comtag:blogger.com,1999:blog-34692233.post-41955017093522649522011-03-21T14:21:44.482+00:002011-03-21T14:21:44.482+00:00Hi Glyn-
Thanks for this update on the changing l...Hi Glyn-<br /><br />Thanks for this update on the changing landscape of enterprise OSGi development.<br /><br />One concern I have is this: with the efforts being made to make it easier (or really just make it possible) for "traditional" enterprise Java development to transition to an OSGi deployment model, I worry that we're adding big layers of complexity to the already significant list of things that a developer may need to understand to use OSGi. I'm not sure that is a winning strategy for OSGi, at least not without additional efforts to make sure to improve the simpler OSGi stack story, and promote a non-JEE development strategy as well.<br /><br />Years ago I turned to an OSGi development strategy specifically as a way of escaping the crazy, clunky, crufty, and downright odd stuff going on with JEE development. I really don't want to have anything at all to do with JNDI, WAR files, and all the rest of those specs. I really don't think most of those actually help the enterprises that adopt them, and I feel like OSGi, on the other hand, really does have a concrete value in designing software.<br /><br />At my company, we adopted Spring DM (not DM Server), which has been, in balance, a big win for us, due to improved ability to manage service-dependency code, as well as giving us more flexible dependency injection (we use the javaconfig stuff). For a while Spring DM has seemed to be in limbo, and it hasn't been very clear when it would be safe to transition to Gemini Blueprint.<br /><br />But I guess my point is that even adding Spring DM/blueprint to "raw" OSGi is a significant increase in what a developer has to learn about to make use of an OSGi stack. So I find myself wishing that more effort would be put into getting the lower-level OSGi house in order, before adding on all the other stuff to try to court the enterprise developers who may not be that interested in showing up anyhow.<br /><br />-DaveDavehttps://www.blogger.com/profile/10149571108351823991noreply@blogger.com