Hello, I didn't have the wildcard at the end. That enabled all Import-Package statements.
Did this change at some point in bnd's history? If I remember correctly, when I started building OSGi projects with bnd 0.0.384, it helpfully complained when I defined the Import-Package statement and forgot some imports. Now, it will tell me (with an explicit Import-Package header) when I've included an import for something I don't use (like "javax.*") but it won't tell me when I've forgotten. So by adding the "catch-all", it works with the caveat that I don't getted nagged to remind me (with a detailed build failure) that I might also want to specify a version range... The risk is that if the bundle gets deployed with a different version of the package, the dependency might be satisfied but because it can match any version of the package, I might get LinkageErrors... The trailing "*" means that more discipline is required to think about checking the generated MANIFEST.MF and watching commits from all contributors. It also means that I catch things needing optional resolution only when deploying, not when building. Given then that BND can indicate "things I imported but didn't need to", it would be very nice when using non-default import headers if it could also warn that "there are things you should import but didn't". Thanks for the feedback. Christopher On 2 November 2012 18:42, Neil Bartlett <[email protected]> wrote: > Did you remember the catch-all "*" at the end of the import-package > statement? > > -- > Neil Bartlett > Sent from a phone > > > On Friday, 2 November 2012 at 17:19, Christopher BROWN wrote: > > > Hello, > > > > Using current builds of BND (GitHub/Cloudbees), and referring to the > > documentation for BND, I'm observing odd behavior. > > > > It seems that BND only adds "javax" packages automatically to the > > MANIFEST.MF when the ".bnd" file contains NO "Import-Package" directive. > > However, I need to add explicit headers because BND can't guess the > > version ranges, so I add the headers manually with the version ranges. > And > > suddenly, BND doesn't seem to detect and add the "javax" packages any > more. > > > > Therefore, I'm getting ClassNotFoundExceptions from Apache Felix at > runtime > > (with the helpful message telling me that the JDK and Felix export it) > > because there's no Import-Package header. This is similar to "classic" > > classpath problems in Java in that the failure occurs only when a > specific > > code path is executed... > > > > I can test this by adding a dummy line such as: > > javax.sql.DataSource = null; > > > > ...anywhere in the bundle. This only fails when the JVM reaches this > code, > > it doesn't prevent the bundle loading. Apache Felix obviously can't > detect > > the problem when resolving the bundle because it's not explicitly > imported, > > because BND isn't adding it. > > > > However, if I put say "javax.foobar.*" in my directive, BND gives me a > > warning. > > > > Is this a bug in BND ? Is there a way to make it "grumpy" so that it'll > > refuse to build my bundle if my imports are wrong? > > > > Thanks, > > Christopher > > > > > > >
