|
From: Thomas R. C. <tho...@gm...> - 2008-07-07 18:16:37
|
On Friday 04 July 2008, Lieven Doclo escreveu: > Hi guys, > > Been reading all the posts here and been comtemplating on OSGi. And > frankly, as a business application developers, I really don't see the > additional benefit of a modular system on a GUI level. Perhaps I'm thick, I > don't know, but I really can't find a reason to provide a modular system on > a GUI framework system. > > Most application I come in contact with don't have a modular design > (actually, that's incorrect, but not in the modular sense we're talking > about here). Enterprise custom-built application don't need plugin > functionality (although it could be handy on a development level, granted). > They almost always see their thick-client gui as a entire module (in the > sense we're talking about here), which might be split up in different > modules (in the more traditional way, for development purposes). > > Don't get me wrong, I do see OSGi as a good thing, but for clearly defined > concerns (dao, service, webservice, domain (although disputable, who would > want to take down a POJO layer...) and webstart GUI as a single module)... > Using OSGi for GUI just seems overkill, could anyone give me an example on > how he or she would split up his GUI application, 'cause that would be > great. > > Please enlighten me, let me see the OSGi light :). We are developing a suite of applications using spring rcp. They all have a common core, but include a different set of spring beans, separated out into different xml files. It is somewhat painful to deal with all this and I hope that an osgi base might make it easier. Could certainly be wrong. But we have applications that deal with a core set of common objects, but are targeted for different users and which all have some additional specialized beans. It would be nice to be able to handle all that gracefully and easily. We have a LOT of spring bean defs, probably too many. And all of them can be overwhelming. |