Hi Grzegorz,
I have a similar idea in Karaf Cave: provide FER (Feature Enterprise
Repository) and providing "OSGi bundles on the fly" with metadata.
I gonna read your e-mail "carefully and in details" and I will get back
to you.
Regards
JB
On 04/04/2014 09:32 AM, Grzegorz Grzybek wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
