felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher BROWN <br...@reflexe.fr>
Subject Re: BND and javax.* packages
Date Sun, 04 Nov 2012 09:14:02 GMT
Hello again,

So I think I understand.  To summarise :
- if a ".bnd" file doesn't contain Import-Package, then it implies "*"
- if a ".bnd" file *does* contain Import-Package, then the "bnd" tool
trusts it and doesn't warn about missing imports
- it is highly recommended to add ";*" at the end of Import-Package to
avoid missing anything
- the output jar will only contain things referred to by Export-Package,
Private-Package, and Include-Resource (and pulls them from the classpath)
- the output Import-Package header will automatically include version
ranges as described on http://www.aqute.biz/Bnd/Versioning from any other
JARs made visible via the "classpath" parameter, so I should provide either
"package-info.class" files in each package, or "packageinfo" files.  The
Export-Package header of bundles on the classpath isn't used because
versioning is supposed to be at package level, not bundle level (this
assertion is less clear to me, referring to the "Versioning" page).

I'll give it a try along these lines.  Will probably need to tweak the
build scripts a bit, especially to push packageinfo into every directory.

Thanks for all your help, it's very much appreciated. I've also just
spotted the bnd list on google groups, will post there in future for this
subject...


--
Christopher



On 3 November 2012 22:44, Neil Bartlett <njbartlett@gmail.com> wrote:

> Christopher,
>
> Some comments inline below.
>
> On Sat, Nov 3, 2012 at 8:18 PM, Christopher BROWN <brown@reflexe.fr>
> wrote:
>
> > Hi Dennis,
> >
> > My goal here is to have "bnd" (not bndtools, which is as I understand
> it, a
> > plugin for Eclipse that extends bnd) work using the command line and
> ".bnd"
> > files, as well as the Ant task, ensure that my own bundles refer to their
> > dependencies with version ranges, and not just the package name.  Neil
> > Bartlett had indicated that the solution involved the "build path" but I
> > was unclear if he was referring to something in the normal "bnd" features
> > or an aspect of an Eclipse project files.
> >
>
> All of the features I described are built into bnd, not Bndtools. You're
> correct that Bndtools is an Eclipse plugin built on top of bnd, but for
> "offline" compilation we use bnd from ANT. There is absolutely no
> requirement to use Bndtools or Eclipse.
>
>
> > I don't use bnd for compilation, I use bnd to assemble OSGi bundle jars
> > with correct OSGi manifests.
>
>
> That's okay, nobody uses bnd for compilation because it's not a compiler.
> It's only a tool for assembling bundles from existing compiled class files.
>
>
> > Compilation is handled by Ant, not by any
> > specific IDE (we allow usage of IntelliJ, Netbeans, Eclipse and the
> command
> > line ; Eclipse isn't the default or mandatory option) ; specifically, it
> > can loop over multiple bundles (using ant-contrib's foreach task or
> > targeted compilation using antcall).  So the project isn't aligned with
> any
> > conventional Eclipse project template (I assume that's what you mean by
> > "relative to the root of your project").
> >
> > Non-OSGi jars are not a problem for me because they don't contain usable
> > versioning info.  OSGi jars are a problem for me because the "*"
> catch-all
> > import just adds a header for the package, without the version.  And I'm
> > not clear on how to leverage these manifests with bnd.
> >
> > So it *might* be on the way to what I'm looking for, but I don't see how
> to
> > apply this to either the Ant task or a BND file.
> >
>
> I don't really understand what is not being understood. Sorry. If you put
> the *same* JAR files on the bnd classpath (which is what I meant by
> "buildpath") as you put on the javac classpath then bnd will pick up any
> version information that it can find in those JARs.
>
> Regards,
> Neil
>
>
> >
> > Thanks,
> > Christopher
> >
> >
> >
> > On 3 November 2012 17:42, Dennis Geurts <dennis.geurts@luminis.eu>
> wrote:
> >
> > > 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 <brown@reflexe.fr> 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 <njbartlett@gmail.com> 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
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message