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 possible) /peter On 12/4/06, Emil Eifrém <[EMAIL PROTECTED]> wrote:
Hi Peter. Thanks for your reply. On 12/4/06, Peter Kriens <[EMAIL PROTECTED]> 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
