Bugzilla – Full Text Bug Listing
| Summary: | PDE-generated build.xml ignores additional.bundles in build.properties | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Adrian Price <adrianp.quatinus> |
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, curtis.windatt.public, daniel_megert, markus.kell.r, tjbishop, torkildr |
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Adrian Price
The fact that PDE Build does not consider the additional.bundles property can lead to a slightly different issue. The property is not intended to add anything to the build classpath, but instead allow the workspace to build when there are indirect dependencies. Another bundle should be adding the additional bundle as a real (manifest) dependency. The problem is that the access rules PDE Build creates are based on the manifest dependencies. In PDE UI, we add access rules for all public packages for additional.bundles entries. In PDE Build, this doesn't happen leading to access restriction warnings or errors. A workaround for this case is to reduce the severity and ignore the access restrictions as the bundle can still be built. (In reply to Curtis Windatt from comment #1) > The property is not intended to add > anything to the build classpath, but instead allow the workspace to build > when there are indirect dependencies. So additional.bundles was just meant as a workaround for bug 73957? > Another bundle should be adding the > additional bundle as a real (manifest) dependency. Yeah, but that's exactly what users don't want to do. OSGi dependencies in the manifest are runtime dependencies, but this bug is about compile/build-time dependencies. There's nothing in OSGi that represents build-time dependencies. The best we can do is use ... Require-Bundle: compile.time.required.bundle.id;resolution:=optional ... which is wrong (since the bundle is never required at run time), but it often works out (except that p2 may install it and the runtime may load it unnecessarily). This issue continues to cause a variety of nasty problems for us, because it forces us to add a completely unnecessary and misleading Require-Bundle...resolution=optional header. We are seeing CCEs as a consequence of OSGi resolving Import-Package to the wrong JAR file, that coincidentally just happens to be present in the runtime. I too would take issue with the assertion in Comment 1: "The property is not intended to add anything to the build classpath...". Whatever the original intentions behind this capability, the UI states clearly: "Augment the plug-in development classpath with the following dependencies without adding them to the MANIFEST.MF file". This is precisely what such use cases require, i.e., to make sure some extra bundles are present on the development classpath, irrespective of whether they represent transitive (but non-exported) dependencies or entirely independent JARs. Whichever way you look at it, this setting does not do what it says on the tin. As to the claim that the present behaviour is by design, in that case 1.) the functionality is misleadingly described in the UI and 2.) excludes this very important 'code generation' use case. The jars.extra.classpath property which is set by the "Extra Classpath Entries" in the build.properties editor should support a platform url like "platform:/plugin/org.foo.plugin". It is not required that the url point to an actual jar. This would get resolved to the appropriate location at build time for the built version of the org.foo.plugin bundle. I just filed bug 436469 as a request for proper compile-time dependencies in the manifest. Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix. Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix. |