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
