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 #6111] Fri, 01 September 2006 22:40 Go to next message
Philippe Ombredanne is currently offline Philippe Ombredanne
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
Re: Dynamic bundle wrapping/manifest injection [message #6141 is a reply to message #6111] Sun, 03 September 2006 03:08 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3214
Registered: July 2009
Senior Member
Hi Philippe,
This sounds very close to what I proposed in the thread "ISiteFactory implementation on top
of the Buckminster Maven provider?" news://news.eclipse.org:119/eaicof$km1$2@utils.eclipse.org.

Any comments on that proposal?

Kind Regards,
Thomas Hallgren


Philippe Ombredanne wrote:
> 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
>
>
Re: Dynamic bundle wrapping/manifest injection [message #6200 is a reply to message #6111] Sun, 03 September 2006 20:34 Go to previous messageGo to next message
Eclipse User
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com

Philippe Ombredanne wrote:

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

Can you say more about what problem this solves? Look at what people
doing today. Basically they get foo.jar from the orginator (in binary
form) and put it in a plugin project (likely useing the PDE wizard).
The build for this project basically just packages that JAR (or its
contents) as a plugin with the appropriate manifests and other gorp.
For the most part this works. Orbit is simply seeking to centralize
this and make the process more consistent.

Making things more dynamic is always fun but we also have increased
legal issues. We in fact don't want people to dynamically get a version
of a bundle. We want them to get the one that was crafted and approved
for use in Eclipse projects. The packaging process (e.g., build) must
be repeatable as with any other plugin build we don't have to do it more
than once.

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

This makes me nervous. I'm not saying that the usecases don't exist but
we should try to avoid them like the plague. Making it easier to do
something that we don't want to have happen does not seem like a good thing.

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

Yup. There has been discussion and debate over that for years. Being
so bold as to state a "convention" for this it basically was as follows
(within the Eclipse project anyway)
"If the plugin is just a simple packaging of the original function, then
use the originator's namespace. If we are adding/modifying the function
then use the eclipse namespace"

IMHO this is a very challenging decision to make. Stepping back a bit
however, it may be the case that it doesn't really matter all that much.
We should look to other communities such as Apache Felix that are
facing similar dilemmas and see if we can come to a consensus.

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

We may get there over time. For now Orbit will be a win if it simply
provides a common place and way for doing the work that is being
repeated numerous time within Eclipse (and elsewhere). The real hope is
that in the future more and more JAR providers will provide bundles
natively so Orbit will just be a repo!

Jeff
Re: Dynamic bundle wrapping/manifest injection [message #6244 is a reply to message #6141] Mon, 04 September 2006 00:52 Go to previous messageGo to next message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
Thomas:
I could see where you guys are goind, and and I will join the discussion.
:-P

--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:eddv16$6ol$1@utils.eclipse.org...
> Hi Philippe,
> This sounds very close to what I proposed in the thread "ISiteFactory
implementation on top
> of the Buckminster Maven provider?"
news://news.eclipse.org:119/eaicof$km1$2@utils.eclipse.org.
>
> Any comments on that proposal?
>
> Kind Regards,
> Thomas Hallgren
>
>
> Philippe Ombredanne wrote:
> > 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
> >
> >
Re: Dynamic bundle wrapping/manifest injection [message #6274 is a reply to message #6200] Mon, 04 September 2006 13:11 Go to previous message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
Jeff:
Thanks for your answers.
I think a limited scope is as you state a good way to get successful and
useful quickly.
> Can you say more about what problem this solves?
What I had in mind is much more wider in scope, more somethng along the
lines of what does http://www.worldofjava.org/
Cordially


--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:edfsdm$gnm$1@utils.eclipse.org...
> Philippe Ombredanne wrote:
>
> > 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.
>
> Can you say more about what problem this solves? Look at what people
> doing today. Basically they get foo.jar from the orginator (in binary
> form) and put it in a plugin project (likely useing the PDE wizard).
> The build for this project basically just packages that JAR (or its
> contents) as a plugin with the appropriate manifests and other gorp.
> For the most part this works. Orbit is simply seeking to centralize
> this and make the process more consistent.
>
> Making things more dynamic is always fun but we also have increased
> legal issues. We in fact don't want people to dynamically get a version
> of a bundle. We want them to get the one that was crafted and approved
> for use in Eclipse projects. The packaging process (e.g., build) must
> be repeatable as with any other plugin build we don't have to do it more
> than once.
>
> > 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.
>
> This makes me nervous. I'm not saying that the usecases don't exist but
> we should try to avoid them like the plague. Making it easier to do
> something that we don't want to have happen does not seem like a good
thing.
>
> > 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.
>
> Yup. There has been discussion and debate over that for years. Being
> so bold as to state a "convention" for this it basically was as follows
> (within the Eclipse project anyway)
> "If the plugin is just a simple packaging of the original function, then
> use the originator's namespace. If we are adding/modifying the function
> then use the eclipse namespace"
>
> IMHO this is a very challenging decision to make. Stepping back a bit
> however, it may be the case that it doesn't really matter all that much.
> We should look to other communities such as Apache Felix that are
> facing similar dilemmas and see if we can come to a consensus.
>
> > 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.
>
> We may get there over time. For now Orbit will be a win if it simply
> provides a common place and way for doing the work that is being
> repeated numerous time within Eclipse (and elsewhere). The real hope is
> that in the future more and more JAR providers will provide bundles
> natively so Orbit will just be a repo!
>
> Jeff
Re: Dynamic bundle wrapping/manifest injection [message #561442 is a reply to message #6111] Sun, 03 September 2006 03:08 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3214
Registered: July 2009
Senior Member
Hi Philippe,
This sounds very close to what I proposed in the thread "ISiteFactory implementation on top
of the Buckminster Maven provider?" news://news.eclipse.org:119/eaicof$km1$2@utils.eclipse.org

Any comments on that proposal?

Kind Regards,
Thomas Hallgren


Philippe Ombredanne wrote:
> 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
>
>
Re: Dynamic bundle wrapping/manifest injection [message #561519 is a reply to message #6111] Sun, 03 September 2006 20:34 Go to previous message
Jeff McAffer is currently offline Jeff McAffer
Messages: 104
Registered: July 2009
Senior Member
Philippe Ombredanne wrote:

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

Can you say more about what problem this solves? Look at what people
doing today. Basically they get foo.jar from the orginator (in binary
form) and put it in a plugin project (likely useing the PDE wizard).
The build for this project basically just packages that JAR (or its
contents) as a plugin with the appropriate manifests and other gorp.
For the most part this works. Orbit is simply seeking to centralize
this and make the process more consistent.

Making things more dynamic is always fun but we also have increased
legal issues. We in fact don't want people to dynamically get a version
of a bundle. We want them to get the one that was crafted and approved
for use in Eclipse projects. The packaging process (e.g., build) must
be repeatable as with any other plugin build we don't have to do it more
than once.

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

This makes me nervous. I'm not saying that the usecases don't exist but
we should try to avoid them like the plague. Making it easier to do
something that we don't want to have happen does not seem like a good thing.

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

Yup. There has been discussion and debate over that for years. Being
so bold as to state a "convention" for this it basically was as follows
(within the Eclipse project anyway)
"If the plugin is just a simple packaging of the original function, then
use the originator's namespace. If we are adding/modifying the function
then use the eclipse namespace"

IMHO this is a very challenging decision to make. Stepping back a bit
however, it may be the case that it doesn't really matter all that much.
We should look to other communities such as Apache Felix that are
facing similar dilemmas and see if we can come to a consensus.

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

We may get there over time. For now Orbit will be a win if it simply
provides a common place and way for doing the work that is being
repeated numerous time within Eclipse (and elsewhere). The real hope is
that in the future more and more JAR providers will provide bundles
natively so Orbit will just be a repo!

Jeff
Re: Dynamic bundle wrapping/manifest injection [message #561577 is a reply to message #6141] Mon, 04 September 2006 00:52 Go to previous message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
Thomas:
I could see where you guys are goind, and and I will join the discussion.
:-P

--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:eddv16$6ol$1@utils.eclipse.org...
> Hi Philippe,
> This sounds very close to what I proposed in the thread "ISiteFactory
implementation on top
> of the Buckminster Maven provider?"
news://news.eclipse.org:119/eaicof$km1$2@utils.eclipse.org
>
> Any comments on that proposal?
>
> Kind Regards,
> Thomas Hallgren
>
>
> Philippe Ombredanne wrote:
> > 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
> >
> >
Re: Dynamic bundle wrapping/manifest injection [message #561615 is a reply to message #6200] Mon, 04 September 2006 13:11 Go to previous message
Philippe Ombredanne is currently offline Philippe Ombredanne
Messages: 386
Registered: July 2009
Senior Member
Jeff:
Thanks for your answers.
I think a limited scope is as you state a good way to get successful and
useful quickly.
> Can you say more about what problem this solves?
What I had in mind is much more wider in scope, more somethng along the
lines of what does http://www.worldofjava.org/
Cordially


--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Jeff McAffer" <jeff_mcaffer@REMOVE.ca.ibm.com> wrote in message
news:edfsdm$gnm$1@utils.eclipse.org...
> Philippe Ombredanne wrote:
>
> > 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.
>
> Can you say more about what problem this solves? Look at what people
> doing today. Basically they get foo.jar from the orginator (in binary
> form) and put it in a plugin project (likely useing the PDE wizard).
> The build for this project basically just packages that JAR (or its
> contents) as a plugin with the appropriate manifests and other gorp.
> For the most part this works. Orbit is simply seeking to centralize
> this and make the process more consistent.
>
> Making things more dynamic is always fun but we also have increased
> legal issues. We in fact don't want people to dynamically get a version
> of a bundle. We want them to get the one that was crafted and approved
> for use in Eclipse projects. The packaging process (e.g., build) must
> be repeatable as with any other plugin build we don't have to do it more
> than once.
>
> > 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.
>
> This makes me nervous. I'm not saying that the usecases don't exist but
> we should try to avoid them like the plague. Making it easier to do
> something that we don't want to have happen does not seem like a good
thing.
>
> > 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.
>
> Yup. There has been discussion and debate over that for years. Being
> so bold as to state a "convention" for this it basically was as follows
> (within the Eclipse project anyway)
> "If the plugin is just a simple packaging of the original function, then
> use the originator's namespace. If we are adding/modifying the function
> then use the eclipse namespace"
>
> IMHO this is a very challenging decision to make. Stepping back a bit
> however, it may be the case that it doesn't really matter all that much.
> We should look to other communities such as Apache Felix that are
> facing similar dilemmas and see if we can come to a consensus.
>
> > 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.
>
> We may get there over time. For now Orbit will be a win if it simply
> provides a common place and way for doing the work that is being
> repeated numerous time within Eclipse (and elsewhere). The real hope is
> that in the future more and more JAR providers will provide bundles
> natively so Orbit will just be a repo!
>
> Jeff
Previous Topic:Source vs. binaries vs. docs/javadocs
Next Topic:Buckminster and Orbit
Goto Forum:
  


Current Time: Tue Jul 22 11:40:58 EDT 2014

Powered by FUDForum. Page generated in 0.04679 seconds