Hi Christopher, Chiming in on the conversation... If I'm correct, the best way to include non-osgi jars is to mention them in your bnd classpath by pointing to them, relatively to the root of your project and setting the version to 'file'. (e.g. lib/xx.jar;version=file)
This way bnd(tools) will pick them up and put them in the classpath, required for compilation. Is that what you are looking for? Regards, Dennis Christopher BROWN <[email protected]> wrote: >Hello > > >I do indeed have the JAR files available as part of the build process, because >as you say, javac needs them. However, I can't see any parameter for setting >the "build path" in the documentation for BND (I'm assuming >that http://www.aqute.biz/Bnd/Format is where I should be looking). I can see >the "classpath" attribute for the Ant task ("-classpath" in the ".bnd" file), >but as far as I understand from the documentation, that's just the source from >which BND will pull classes into the output bundle ".jar" file. > > >Do you mean that I should include classes and jar files into the "classpath" >parameter so that BND can see them to determine version ranges? Is there a >risk of accidentally pulling in the dependencies into the output ".jar" file >(in other words, what stops BND from doing this : is it the combination of >Export-Package and Private-Package ?) ? > > >Or is the "build path" something that's managed by Eclipse, and obtained from >the ".classpath" file/parameter (we don't allow dependencies on specific IDEs >where I work, and Eclipse is only chosen by one or two team members) ? > > >Or is it something to do with the "source path" referred to by >http://www.aqute.biz/Bnd/Ant ? I can't figure out what it's supposed to do or >what format of information it expects. > > >Thanks, > >Christopher > > > >On 2 November 2012 23:45, Neil Bartlett <[email protected]> wrote: > >Yes you're correct that bnd does not NEED the packages referred to. If the >bytecode in the JAR contains a reference to package "org.example" then that >will be added as an Import-Package, irrespective of whether bnd can actually >see "org.example" somewhere. > >However, if bnd CAN see that package somewhere, it does its best to use all >the information available. So if you put the JAR containing "org.example" on >the buildpath, and if that JAR happens to be a bundle with an Export-Package >header that exports "org.example" as (say) version 1.0, then bnd will use that >information to generate an Import-Package that with version range [1.0,2.0) or >[1.0,1.1), depending on whether your bundle is a consumer or a produce of the >API in question. > >If you're building your bundles from source then you basically always have the >dependency JARs around, because javac needs them. Therefore if you can arrange >for your dependencies to be bundles rather than plain JARs, and if you pass >the same buildpath to bnd that you gave to the javac compiler, then the >version ranges will be inferred. > >Because of this capability, I hardly ever have to manually override the >Import-Package statement in my own bundles. It's only really necessary when >I'm wrapping a pre-compiled binary JAR from somewhere else. > >Regards >Neil > > > > > > > > Christopher BROWN > >2 November 2012 22:28 > >Hello, > >If there's a solution for bnd to determine the version range, then that >sounds like the solution I'm looking for. However, I can't see how to do >this... I use BND in two ways, either at the command line with a ".bnd" >file, and using the Ant task. The only way I can see to set the classpath >is for the class files that I want BND to pull into the output JAR. After >reading various sources (including "osgibook_preview_20091217.pdf"), I was >under the impression that BND determines the imports by inspecting the >bytecode of the classes that make up the bundle, and doesn't actually >require (or have any way of specifying) the packages and JAR files referred >to. > >So I can't see how to tell it to inspect other JAR files to extract the >version of different Export-Package headers. Could you point me to an >example of how I can make a ".bnd" file and the Ant task add versioning >information to the Import-Package header without me actually specifying it? > >Thanks, >Christopher > > > > > > > > > Neil Bartlett > >2 November 2012 22:06 > >The requirement for the trailing star has never changed, as far as I remember. > >If you use Bndtools it will nag you that the trailing star is missing, and >offer a quick-fix to put it there. Of course it can only be a warning because >there are scenarios where the user really does know best and wants to >explicitly define every import on the bundle. > >For the version issue, it's best if you can build your bundle against other >bundles that have versioned exports. If you do this then bnd will >automatically apply Semantic Versioning rules to set the correct import range. > >Regards >Neil > > > > > > Christopher BROWN > >2 November 2012 21:36 > >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 > > > > > > > > Neil Bartlett > >2 November 2012 17:42 > >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: > > > > > > > Christopher BROWN > >2 November 2012 17:19 > >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 > >
