Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Orbit » Dynamic bundle wrapping/manifest injection
Dynamic bundle wrapping/manifest injection [message #561402] Sat, 02 September 2006 02:40
Philippe Ombredanne is currently offline Philippe OmbredanneFriend
Messages: 386
Registered: July 2009
Senior Member
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
retrieval place.

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:
location/name/provider/version/license etc...
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
time.

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
universal.

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
engineering,
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.

Cordially


--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
Previous Topic:How many bundles from a library?
Next Topic:Source vs. binaries vs. docs/javadocs
Goto Forum:
  


Current Time: Thu Nov 27 14:56:51 GMT 2014

Powered by FUDForum. Page generated in 0.02736 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software