> From: Markus Keller <markus_kel...@ch.ibm.com> > 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 hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
