Eclipse Community Forums: Orbit » How many bundles from a library?

Help

Home

Home » Eclipse Projects » Orbit » How many bundles from a library?

Show: Today's Messages :: Show Polls :: Message Navigator

How many bundles from a library? [message #4025]

Wed, 12 July 2006 17:16

Eclipse User

Originally posted by: p.p.com

Many apache projects include or require other apache parts to be used. How
many bundles should result from the bundling of such a project?
- One: like it is done currently
- One per included library?

A concrete example, Tomcat includes log4j, commons, naming, servlet, etc.
Should we have one big bundle including all the bits and pieces? Should we
have one bundle for log4j, one bundle for naming, one bundle per piece of
commons?

In case of the "one per included library", it seems that we will likely need
some involvement from the various providers to make sure that the split
works properly.

PaScaL

Report message to a moderator

Re: How many bundles from a library? [message #4389 is a reply to message #4025]

Wed, 12 July 2006 17:51

Eclipse User

Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com

Excellent question. For the most part we should get approval for the
individual components when we think those components are actually
interesting independently. The tomcat case is a good one since the
original use was for Help. They were not interested in exposing any of
these internals (in fact it turns out we have been shipping stuff we
don't need for some time now) so simply took the whole Tomcat download
and bundled it up. As we are evolving various scenarios we actually do
have usecases for servlet api, logging, mx4j, ... quite separate from
Tomcat.

Summary is that this is likely a value judgement and we will learn as we
go but the initial guidance should be one bundle per JAR.

Jeff

Pascal wrote:
> Many apache projects include or require other apache parts to be used. How
> many bundles should result from the bundling of such a project?
> - One: like it is done currently
> - One per included library?
>
> A concrete example, Tomcat includes log4j, commons, naming, servlet, etc.
> Should we have one big bundle including all the bits and pieces? Should we
> have one bundle for log4j, one bundle for naming, one bundle per piece of
> commons?
>
> In case of the "one per included library", it seems that we will likely need
> some involvement from the various providers to make sure that the split
> works properly.
>
> PaScaL
>
>
>
>

Report message to a moderator

Re: How many bundles from a library? [message #4458 is a reply to message #4025]

Wed, 12 July 2006 19:41

Erkki Lindpere

Messages: 90
Registered: July 2009

Member

As a consumer of the various frameworks provided by Eclipse, I would
prefer that each library is in a separate bundle. So if I need those in
my own project, I can have detailed control over what to depend on
without needing to create the wrapping bundles myself.

But this might complicate the packaging of the bundles -- now they need
to be analyzed to find out what bundles or packages they need to declare
dependencies on.

I think it would also make great sense if the bundle naming conventions
were modelled after Java packages like it is for Eclipse projects mostly
i.e. org.apache.log4j, org.apache.commons.chain
In Callisto, at least two bundles use different naming:
org.apache.commons_logging
org.apache.jakarta_log4j (while actually log4j has not even been under
jakarta at least since I started using it two years ago)

Pascal wrote:
> Many apache projects include or require other apache parts to be used. How
> many bundles should result from the bundling of such a project?
> - One: like it is done currently
> - One per included library?
>
> A concrete example, Tomcat includes log4j, commons, naming, servlet, etc.
> Should we have one big bundle including all the bits and pieces? Should we
> have one bundle for log4j, one bundle for naming, one bundle per piece of
> commons?
>
> In case of the "one per included library", it seems that we will likely need
> some involvement from the various providers to make sure that the split
> works properly.
>
> PaScaL
>
>
>
>

Report message to a moderator

Re: How many bundles from a library? [message #6081 is a reply to message #4025]

Sat, 02 September 2006 01:59

Philippe Ombredanne

Messages: 386
Registered: July 2009

Senior Member

PaScaL wrote:
> Many apache projects include or require other apache parts to be used. How
> many bundles should result from the bundling of such a project?
> - One per included library?
It is appealing intellectually and disk space-wise to remove duplications.
And ship only once a required jar/version.

> - One: like it is done currently
This is less appealing but has the advantage to avoid issues when some
working assembly of libs just works like that, and breaking it may involve
upstream code changes or patching.
So there is a potential risk to be swallowed in the spiral of patching with
the one jar == one bundle.

Now there is also a funny side effect to the one jar== one bundle.
That bundle manifest -since it would be made for general consumption- cannot
know its friends.
Therefore, a simple practice could be to say: we'll craft a manifest and
export all packages.
That can lead to interesting situations...I recently screwed up my base
eclipse platfrom installation with a plugin that had a high bundle id
(lexicographically speaking meaning it showed up before eclipse base bundles
in alpha order).
That bundle was exporting all its included jars including an outdated
version of of the w3c xml APIs.
Somehow, some platform bundle was using an import-package and caught those
older versions, and eclipse was screwed.
That nasty side effects can only show up at runtime, is almost impossible to
plan ahead and would show up only in a certain configuration of planets for
sure.
But it disturbs orbiting :-P

So just some thoughts needs to be put in this, imho:
one jar vs. many jars and what is being exported from some jar provided as a
bundle (which may be tricky as beyong public/private, everything else like
"internals" is a just a project by project or documentation convention) may
have unintented side effects.
To the point that the need of custom manifests may occur, like saying:
"I need a certain manifest when I use some Apache jar xyz", and some other
project may need to have a different manifest.
The alternative is juggle with one's own imports and imports order and
constraints in some delicate way.

I acn also see the need for some serious education/documentation for bundle
and plugins developers to be made on how to manage their manifest
constraints, the version filters, imports, required bundles, the x-friends
and so on.
Some tooling may help too.

Just some 2 cents. But as I deal with many plugins from many plugin devs,
what I see in the wild is often brutal.

--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Pascal" <p@p.com> wrote in message news:e93ap1$ati$1@utils.eclipse.org...
> Many apache projects include or require other apache parts to be used. How
> many bundles should result from the bundling of such a project?
> - One: like it is done currently
> - One per included library?
>
> A concrete example, Tomcat includes log4j, commons, naming, servlet, etc.
> Should we have one big bundle including all the bits and pieces? Should we
> have one bundle for log4j, one bundle for naming, one bundle per piece of
> commons?
>
> In case of the "one per included library", it seems that we will likely
need
> some involvement from the various providers to make sure that the split
> works properly.
>
> PaScaL

Report message to a moderator

Re: How many bundles from a library? [message #6097 is a reply to message #6081]

Sat, 02 September 2006 02:24

Philippe Ombredanne

Messages: 386
Registered: July 2009

Senior Member

Note that most of those concerns are already clearly mentioned in the
project proposal. :-)
I would interested to contribute there.
Feel free to add me / easyeclipse.org as an interested party :-)

--
Cheers, Philippe
philippe ombredanne | nexB
1 650 799 0949 | pombredanne at nexb.com
http://www.nexb.com
http://EasyEclipse.org
"Philippe Ombredanne" <pombredanne@nexb.com> wrote in message
news:edap18$nh8$1@utils.eclipse.org...
> PaScaL wrote:
> > Many apache projects include or require other apache parts to be used.
How
> > many bundles should result from the bundling of such a project?
> > - One per included library?
> It is appealing intellectually and disk space-wise to remove duplications.
> And ship only once a required jar/version.
>
> > - One: like it is done currently
> This is less appealing but has the advantage to avoid issues when some
> working assembly of libs just works like that, and breaking it may involve
> upstream code changes or patching.
> So there is a potential risk to be swallowed in the spiral of patching
with
> the one jar == one bundle.
>
> Now there is also a funny side effect to the one jar== one bundle.
> That bundle manifest -since it would be made for general consumption-
cannot
> know its friends.
> Therefore, a simple practice could be to say: we'll craft a manifest and
> export all packages.
> That can lead to interesting situations...I recently screwed up my base
> eclipse platfrom installation with a plugin that had a high bundle id
> (lexicographically speaking meaning it showed up before eclipse base
bundles
> in alpha order).
> That bundle was exporting all its included jars including an outdated
> version of of the w3c xml APIs.
> Somehow, some platform bundle was using an import-package and caught those
> older versions, and eclipse was screwed.
> That nasty side effects can only show up at runtime, is almost impossible
to
> plan ahead and would show up only in a certain configuration of planets
for
> sure.
> But it disturbs orbiting :-P
>
> So just some thoughts needs to be put in this, imho:
> one jar vs. many jars and what is being exported from some jar provided as
a
> bundle (which may be tricky as beyong public/private, everything else like
> "internals" is a just a project by project or documentation convention)
may
> have unintented side effects.
> To the point that the need of custom manifests may occur, like saying:
> "I need a certain manifest when I use some Apache jar xyz", and some other
> project may need to have a different manifest.
> The alternative is juggle with one's own imports and imports order and
> constraints in some delicate way.
>
> I acn also see the need for some serious education/documentation for
bundle
> and plugins developers to be made on how to manage their manifest
> constraints, the version filters, imports, required bundles, the x-friends
> and so on.
> Some tooling may help too.
>
> Just some 2 cents. But as I deal with many plugins from many plugin devs,
> what I see in the wild is often brutal.
>
>
> --
> Cheers, Philippe
> philippe ombredanne | nexB
> 1 650 799 0949 | pombredanne at nexb.com
> http://www.nexb.com
> http://EasyEclipse.org
> "Pascal" <p@p.com> wrote in message news:e93ap1$ati$1@utils.eclipse.org...
> > Many apache projects include or require other apache parts to be used.
How
> > many bundles should result from the bundling of such a project?
> > - One: like it is done currently
> > - One per included library?
> >
> > A concrete example, Tomcat includes log4j, commons, naming, servlet,
etc.
> > Should we have one big bundle including all the bits and pieces? Should
we
> > have one bundle for log4j, one bundle for naming, one bundle per piece
of
> > commons?
> >
> > In case of the "one per included library", it seems that we will likely
> need
> > some involvement from the various providers to make sure that the split
> > works properly.
> >
> > PaScaL
>
>

Report message to a moderator

Re: How many bundles from a library? [message #561055 is a reply to message #4025]

Wed, 12 July 2006 17:51

Jeff McAffer

Messages: 104
Registered: July 2009

Senior Member

Excellent question. For the most part we should get approval for the
individual components when we think those components are actually
interesting independently. The tomcat case is a good one since the
original use was for Help. They were not interested in exposing any of
these internals (in fact it turns out we have been shipping stuff we
don't need for some time now) so simply took the whole Tomcat download
and bundled it up. As we are evolving various scenarios we actually do
have usecases for servlet api, logging, mx4j, ... quite separate from
Tomcat.

Summary is that this is likely a value judgement and we will learn as we
go but the initial guidance should be one bundle per JAR.

Jeff

Pascal wrote:
> Many apache projects include or require other apache parts to be used. How
> many bundles should result from the bundling of such a project?
> - One: like it is done currently
> - One per included library?
>
> A concrete example, Tomcat includes log4j, commons, naming, servlet, etc.
> Should we have one big bundle including all the bits and pieces? Should we
> have one bundle for log4j, one bundle for naming, one bundle per piece of
> commons?
>
> In case of the "one per included library", it seems that we will likely need
> some involvement from the various providers to make sure that the split
> works properly.
>
> PaScaL
>
>
>
>

Report message to a moderator