felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Neubauer" <pe...@neubauer.se>
Subject Re: Bundle plugin: Importing packages from non-bundles
Date Mon, 04 Dec 2006 21:17:27 GMT
Hi Peter,
while reading this i am thinking of one more interesting case.

What about bundles that do not have the source located as class files
under the root of the bundle jar, meaning that the bundle can play a
double role as valid "classic" jar and as a valid bundle?

It is entirely possible, and probably in certain cases, not only
library jars, desirable to package all class files into jars within
bundles. What about maven and the bnd plugin in that case?

- is maven capable of using the resulting bundle as a dependency for
the next bundle (I think not)
- is the bnd plugin capable to figuring out the imports and exports
from only ingoing .jar files, meaning that more or less all bundles
look like library bundles? (I guess that is there  or would be


On 12/4/06, Emil Eifrém <emil@eifrem.com> wrote:
> Hi Peter. Thanks for your reply.
> On 12/4/06, Peter Kriens <Peter.Kriens@aqute.biz> wrote:
> > The manifest looks fine, there seems to be no bundle exporting the
> > org.apache.commons.logging package.
> Actually, in our case it's more like:
>    "The manifest DOESN'T look fine, because there is no bundle
> exporting the org.apache.commons.logging package."
> [snip]
> > If you have suggestions for
> > improving the plugin/bnd then please let me know.
> >
> Yes, we do lack a feature that would make our lives easier.
> First off, we have a few simple principles for our build environment.
> In fact, we have a bunch but here's the gist as relevant for this
> discussion:
>    1. Detect as many problems as possible at compile-time. This means
> we're not too thrilled about the resolution:=optional solution.
> Runtime exceptions is not good enough.
>    2. The POM is the definitive resource for information about a
> project's configuration. All other configuration resources (Eclipse
> files, OSGi manifests) should be generated from it.
>    3. Never ever add a feature (to the build infrastructure) if it
> means we have to update the same information in more than one place
> for frequent changes. (Everything more often than "once per month" is
> frequent.)
> So in our case the POM knows everything about the project. This means
> that ALL dependencies for our source files are listed in the POM. And
> this means that the plugin should be able to just do the Right
> Thing(tm), which in our view is to take dependencies with
> <type>bundle</type>, analyze them and generate Import-Package
> statements for them; and take dependencies with <type>jar</type>, add
> them to Bundle-Classpath and embed them in the bundle.
> This should solve our problems. I realize this is not for all. Some
> people don't have all information in the POM, others have all jar
> files as bundles. But the above functionality combined with the
> behavior for <scope>provided</scope> seems to cover all bases.
> Am I missing something?
> Cheers,
> -EE

View raw message