Modular Java: comparison of OSGI with other systems and approaches and how they can be combined
posted 7 years ago
I'm interested in your opinions on the following topic:
Java (means: Java SE 6, Java EE 6) has no real mechanism for declaring modules and their interdependencies. The topic is quite complicated, and involves among others capabilities like: declarative describtion of modules, their dependencies, versioning, automatic resolving dependencies (using e.g. repositories of modules), etc. There are, however, many approaches/idea/specifications which are linked to this topic somehow. What's interesting, there seems to me that exists clear division between compile-time and runtime. For compile time, we have Maven and Ivy. For runtime, there is OSGI + Spring DM + Spring dm server. There are also other related specification, which I'm not even sure about their current status and scope (JSR-277, JSR-291 - that's actually OSGI, right?, JSR-294). There are also other tools: pax, bundlor etc...
From my point of view it's questionable if the compile/runtime division makes any sense. WOuldn'be be best if maven or ivy used the same module metadata as osgi? There are obviously technical differences and problems here, for example maven uses this silly groupId-artifactId scheme for identificaton (how on earth did they invent this crazy idea instead of single package-based id? I can't imagine).
So the interesting topic is: what's the possible future of this systems/approaches? What are the chances of having them unified and/or integrated? If the OSGi is the clean winner in runtime scope (is it?) is there any chance that we'll have the compile-time system based on OSGI metadata soon?