|Dynamic bundle wrapping/manifest injection [message #6111]
||Fri, 01 September 2006 22:40
| Philippe Ombredanne
Registered: July 2009
Just a not so wild idea for the group...|
There are some common scenario where you already have a well known source or
provider for a certain jars.
(trust me it is not always the case, try for instance to fetch the sources
or binaries of org.apache.wsil4j from wherever which is part of callisto for
WTP... good luck and be my guest :-P )
Let's say anyway you have a public maven repo, or a well known, stable
I understand that one goal of orbit could to provide a set of
Eclipse-legally-and-technically approved third-party jar as bundles for use
in other Eclipse.org projects or elsewhere.
I could see a scenario where a jar info/metadata are maintained in orbit:
and that a bundle could be crafted on the fly from that.
When I speak of bundle wrapping, I mean crafting an appropriate MANIFEST.MF,
or wrapping the jar inside a bundle jar.
That could happen at build time, or at design time as a one time import.
With or without caching.
You could even think of such a dynamic bundle wrapping at install/update
It could help separate the Eclipse.org legal approval issues from the
technology issues, and provide a way to assemble bundles from many sources
with ease (that would even not know that they are providing their jars as an
OSGi bundle too :-) ).
That could be also a way to deal with the cases when different manifests may
be needed by different projects for the same jars. Or provide subset of
those jars as bundles when some jars re-package themselves others' jars. (
an unfortunate yet common scenario).
There can be times when which package is being exported by a bundle is not
And this could also provide a way to craft tooling to avoid naming, imports
or version conflicts.
For instance, Eclipse (as an org) is breaking the rule #1 (in my book) of
using the upstream jar provider namespace for bundle symbolic names for
bundles it provides . The apache related bundles are a good example.
org.apache.ant shoud be a bundle provided by apache imho.
org.eclipse.org.apache.ant could be a name to consider for ant packaged as a
bundle by Eclipse.org.
So while I may be disgressing.... the idea of dynamic manifest injection and
dynamic bundle wrapping could be something to consider...
Think along the lines of MANIFEST.MF engineering, like in byte-code
I understand that this project is not supposed to be primarily about code.
As I read from the proposal:
"This project [Orbit] is not intended to
*support code development
*replace the IP process
*do all the packaging work for teams"
Yet, the code is already there in PDE with New/project/New plugin from
existing jar" :-P and could be put to good use in a larger context of
dynamic bundle provisioning.
And have a way so that:
This project [Orbit] is not intended to:
*support code development, yet may extend/enahnce some existing Eclipse
tooling code for supporting its goals when appropriate
*replace the IP process, yet provides a way to address complex IP situations
gracefully, and dissociate technology from legal issues
*do all the packaging work for teams, but provides the teams a way to
possibly limit their packaging work to metadata on the one hand, and offer
users of the bundles flexibility in how they can consume Orbit bundles on
the other hand.
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com