Re: [equinox-dev] dependency on org.osgi.annotation?

[BJ Hargrave <hargrave@xxxxxxxxxx>]

> From: Markus Keller <markus_keller@xxxxxxxxxx>

> I think we had the same discussion about a year
ago: 
> 
> Bug 436469: Declare compile-time (build-time) dependencies in manifest
> Bug 434243: Import org.eclipse.osgi[.services] as source => compile
> errors for missing @ConsumerType 
> 
> The problem is still the same: Stephan and I think that builds 
> a) should not be monolithic, and 
> b) should not require external dependency information 

Well, first the build which makes org.eclipse.osgi
is OK since it does build. The issue is with someone else's build using
org.eclipse.osgi as a build dependency.

The build-time (aka compile-time) dependencies do
not have to be the same as the runtime dependencies. That is, if you are
making a bundle and using OSGi APIs, then you should compile against the
OSGi API (e.g. osgi.core, osgi.annotations) rather than against an OSGi
implementation (e.g. org.eclipse.osgi). The issue here is that the build
wants to build against the implementation (org.eclipse.osgi) and this causes
issues for JDT trying to display information about a CLASS retention annotation
which is available when building org.eclipse.osgi but not when (improperly)
using org.eclipse.osgi as a compile-time dependency.

> 
> It should be possible to build bundles that depend on other bundles
> by just pointing the build process at the bundle's sources and at
> its pre-built dependencies. 

Again, there is a distinction between compiling against
API or against implementation. A bundle should compile against the API
and not against the implementation.

> 
> But this is currently not possible because build-time dependencies
> are missing in the bundle metadata. 
> From http://www.osgi.org/Technology/WhyOSGi
: 
> "The OSGi programming model realizes the promise of component-based
systems."
> 
> The final step to actually realize this promise would be to allow
> for component-based builds. 

Building against the same bundle you run against is
not necessarily the right thing. You should compile against the lowest
version of the API you need so you can run against any implementation of
a compatible version of the API. That is a component based build.

PDE is the source of problem here in that it treats
the manifest as both an input to the build and an output of the build.
This makes a proper build hard since you cannot easily specify different
jars to compile against (API) than to run against (implementation). Bug
436469 suggests adding more information to the manifest to deal with this
problem. bnd/bndtools is a better component build tool for Eclipse since
it does not use the manifest as a build input which allows for different
compile-time than runtime.

--

BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargrave@xxxxxxxxxx

office: +1 386 848 1781 mobile: +1 386 848 3788