Hello everyone! TL;DR - why don't we drop the ugly META-INF/MANIFEST.MF file and describe OSGi metadata somewhere else?
== LONG VERSION I actually wrote it 5 (five!) years ago[1], but I thought about this again while filtering the emails from SMX4 Jira starting with "Create OSGi bundle for ...". It's sad to see how much dev energy is wasted for such activities as repairing other peoples JARs to make them usable in OSGi/Karaf. It's especially sad that SpringSource, which once had its EBR repository with OSGified versions of everything now needs the same kind of support. --- [1] http://www.theserverside.com/discussions/thread.tss?thread_id=53803#305351 I'd like to pick up this idea again. Generally it's about moving OSGi *metadata* away from this XX century invention which is MANIFEST.MF file (76 chars in line - yikes!) into another XX century invention which is XML file. I always knew that it's not good to mix the things from different worlds (abstraction levels, domains, ...) in one place. That's why metadata (in this case OSGi metadata) is usually placed separately of the data (in this case - JAR file with classes). I know that Java annotations are not example of this separation, but I hope you agree that even if we have annotations, it's good to see a "big picture" in XML file (description, blueprint, spring beans, ...). .NET has this notion of *.manifest file which resides beside the exe/dll file and is used at runtime to change/describe some aspects of running .NET assembly. Don't we have similar situation with OSGi? JAR file contains executable code + resources. OSGi metadata describes the aspects that allow running this code in a OSGi container (or more generally: managed environment). If we could think of moving the metadata from META-INF/MANIFEST.MF to external metadata (XML is just good, readable and ubiquitous format) we would gain the following benefits: - avoiding duplication of JARs in Maven Central. OSGi metadata could be available in regular Maven artifacts with e.g., "osgi" or "osgi-metadata" classifier - more readable and greppable format (how many times have you unpacked the MANIFEST.MF, joined lines and splitted it by comma (but not every comma) to check visually what this bundle really needs/exposes?) - a kind of separation of lifecycles between JAR (code + resources) and it's OSGi metadata. What is the *real* difference (from the OSGi perspective) between "org.apache.servicemix.bundles.antlr-runtime:3.5_1" and "org.apache.servicemix.bundles.antlr-runtime:3.5.1_1"? - we could place more general OSGI metadata which would contain the following attributes: - Bundle-SymbolicName: org.apache.servicemix.bundles.avro (doesn't change between antrl releases!) - Export-Package - changes sometimes (not in every antlr release! - Bundle-Version - the most important one - could be related to e.g., Implementation-Version header from standard MANIFEST.MF, could be postfixed with some number, anything - easier, more elastic management - we could place *two* OSGi manifests for one JAR (two versions for legacy/old bundles), we could place *one*OSGi manifest for *two+* JARs (split packages!) and have native notion of (Karaf) features - faster redeployment (change in OSGi manifest only without reloading the JAR) - less work for Jean-Baptiste Onofré :) - XML format could allow more complex (but still simple) constructs - e.g., "uses constraint groups" which could be referred to exports. One of the most important effects of this change would be better alignment with Maven. As I wrote 5 years ago, for me Maven is for static dependency management and OSGi - for dynamic (it's obvious). But OSGi Chapter 3 "module layer" is partially about static dependencies (at package level). Of course we don't know what Jigsaw people will come with (there was "Jigsaw prototype take 2[2]" but it's quiet on the list right now) but we/you could try make the "module layer" more elastic - without tying the metadata with MANIFEST.MF format - I'm sure it's not revolutionary change, as the metadata after being read is not MANIFEST.MF anymore. Maven repository could just store OSGi metadata as another form of artifact (new classifier). We could use it or no (I heard there are still developers who don't use OSGi) but it would be there - at the reach of single CURL. --- [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2013-August/003328.html I won't write more I hope for a hot (or even just warm) debate best regards Grzegorz Grzybek
