Community
Participate
Working Groups
Assume a fragment "f" for a plugin "p". Further assume that the fragment exports a package "pa". Thus, plugin "p" exports package "pa". Now assume another plugin "p1" that depends on plugin "p" since it uses the package "pa". Within PDE add "p" as a required plugin for "p1". Export "p1" with PDE's "Deployable plug-ins and fragments" export wizard. Error: PDE is not able to *build* the plugin "p1" since it does not recognize package "pa". Further details: - Plugin "p1" developed against a target platform that contains both, the fragment "f" and the plugin "p". - Known workaround: Hack "build.properties" header "jars.extra.classpath" and put the Jar containing package "pa" - very ugly. - News group related thread: News group: eclipse.platform.rcp, thread: Export problems (fragment related) by Daniel Krügler, September 2005.
Because it is not possible to require a fragment, fragments should be treated as optional. Therefore what you are seeing is expected since P1 can not rely that F will always be around. To bypasse this, in cases where you know that P1 will always be shipped with F add into P1 manifest.mf the following line and that will fix your problem: Eclipse-ExtensibleAPI: true Note that this tooling specific markup is only supported in 3.2 so you can develop with 3.2 and still target 3.1.
Plugin development is against a target platform. The target platform comprises a distinct set of fragments and plugins. The set of packages ultimatively seen by other plugins is therefore dependent on the set of fragments and plugins contained in the target platform. If plugin "p" and fragment "f" are contained in the target platform then plugin "p" naturally exports package "pa". (If fragment "f" was not contained in the target platform then plugin "p" would not export package "pa".) I don't think that it is too hard to add this feature to PDE's dynamic classpaths computation.
*** Bug 141734 has been marked as a duplicate of this bug. ***
It is unclear for me why PDE just builds the plugin "p1" without a problem as soon as the fragment "f" is in the workspace but the build fails when "f" is not in the workspace but still contained in the target platform. (This forces us to either import our fragments into the workspace or to apply the dirty trick with the hacked "jars.extra.classpath" entry in the "build.properties" described above.) It is not a question of a missing entry in the "manifest.mf". It is just a lack of PDE's process of *building* the plugin. PDE knows of all fragments and plugins in the target platform, hence, it also knows that plugin "p" exports package "pa". Therefore it should build plugin "p1" without any complaints, even if fragment "f" is not in the workspace. Pascal, did I miss something or did I express myself in an unclear way?
I understand your point, but I would appreciate if you could provide smaple plugins and fragments to help us capture the problem.
(In reply to comment #5) > I understand your point, but I would appreciate if you could provide smaple > plugins and fragments to help us capture the problem. I use Eclipse 3.2 1. Create plug-in "p1": File/New Project.../Plug-in Development/Plug-in Project Next Project name: pluginP1 Next Finish 2. Create plug-in "p": File/New Project.../Plug-in Development/Plug-in Project Next Project name: pluginP Next Finish 3. Create fragment "f": File/New Project.../Plug-in Development/Fragment Project Next Project name: fragmentF Next Host Plug-in/Plug-in ID: pluginP Finish In Package Explorer right-click fragmentF/New Folder Folder name: lib Put into the lib-folder any jar-file that you want to use in plug-in "p1". I put Apache's XSL-FO Processor, as an example. Hence, my lib folder contains the "fop.jar" file. The editor aera of the PDE perspective shows the "fragmentF" editor. Select the "Runtime" tab Classpath/Add... Open "lib" and double-click lib/fop.jar Exported Packages/Add... double-click on "org.apache.fop.apps" (or any other package that you want to use in plug-in "p1"). File/Save 4. Make plug-in "p" a required plug-in for plug-in "p1" In the editor aera click on "pluginP1" Select the "Dependencies" tab Required/Plug-ins/Add... double click on "pluginP" File/Save 5. We now want to use package "org.apache.fop.apps" (or any other package that was given to plug-in "p" via its fragment "f") in plug-in "p1". In Package Explorer right-click pluginP1/Properties Java Build Path/Libraries/Add External JARs... double-click on "fop.jar" Ok In Package Explorer unfold pluginP1/src/pluginp1 right-click package "pluginP1" New Class Name: "MyClass" Finish Put the following (useless) source-code into MyClass.java package pluginp1; import java.io.IOException; import org.apache.fop.apps.Driver; import org.apache.fop.apps.FOPException; public class MyClass { public void runFO2PDF() throws IOException, FOPException { Driver driver = new Driver(); driver.run(); } } File/Save 6. Export plug-in "p" and fragment "f" to the Target-Platform. I take the "standard" Target Platform, in my case "C:\Program Files\eclipse-SDK-3.2". In Package Explorer right-click pluginP/Export... double-click Plug-in Development/Deployable plug-ins and fragments select "Available Plug-ins and Fragments/pluginP and fragmentF" Select the Target Platform: Destination/Directory: "C:\Program Files\eclipse-SDK-3.2" select "Options/Package plug-ins as individual JAR archives" Finish The directory "C:\Program Files\eclipse-SDK-3.2\plugins" should now contain the files "pluginP_1.0.0.jar" and "fragmentF_1.0.0.jar". 7. Now the most important step: Close the fragment project in the workspace. In PackageExplorer right-Click fragmentF/Close Project 8. Export plug-in "p1" to the Target-Platform In Package Explorer right-Click pluginP1/Export... double-click Plug-in Development/Deployable plug-ins and fragments pluginP1 should be selected Other settings should be okay Finish A popup appears: Errors occurred during the operation. A zip file containing the build logs has been generated and placed at "C:\Program Files\eclipse-SDK-3.2". The zipped-logs contains the following messages: # 07.09.06 10:41:53 CEST # Eclipse Java Compiler 0.671, 3.2.0 release, Copyright IBM Corp 2000, 2006. All rights reserved. ---------- 1. ERROR in C:\workspaces\Standard\pluginP1\src\pluginp1\ MyClass.java (at line 11) import org.apache.fop.apps.Driver; ^^^^^^^^^^ The import org.apache cannot be resolved ---------- 2. ERROR in C:\workspaces\Standard\pluginP1\src\pluginp1\MyClass.java (at line 12) import org.apache.fop.apps.FOPException; ^^^^^^^^^^ The import org.apache cannot be resolved ---------- 3. ERROR in C:\workspaces\Standard\pluginP1\src\pluginp1\MyClass.java (at line 21) public void runFO2PDF() throws IOException, FOPException { ^^^^^^^^^^^^ FOPException cannot be resolved to a type ---------- 4. ERROR in C:\workspaces\Standard\pluginP1\src\pluginp1\MyClass.java (at line 22) Driver driver = new Driver(); ^^^^^^ Driver cannot be resolved to a type ---------- 5. ERROR in C:\workspaces\Standard\pluginP1\src\pluginp1\MyClass.java (at line 22) Driver driver = new Driver(); ^^^^^^ Driver cannot be resolved to a type ---------- 5 problems (5 errors) Remarks: - Exporting plug-in "p1" runs without error if the fragment project is in the workspace, that is, if Step 7 was omitted. - Exporting plug-in "p1" runs without error (the fragment project being closed) if I apply the dirty trick described in the first message: Directly hack the "build.properties" of plug-in "p1" setting: jars.extra.classpath = ../../../Triangulum/Entwicklung/libraries/ Apache FOP/build/fop.jar - Another thing that seems to be new in Eclipse 3.2: If I close the plug-in project "pluginP" then Eclipse immediately shows an error in plug-in project "pluginP1". The same question again: Am I programming against my workspace or against the Target Platform. (The latter one should be the right one. I want to do PDE without having to load all required plug-ins and fragments into the workspace.)
After two years, I still think that PDE should be agnostic to fragments in the target platform.
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.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
