Community
Participate
Working Groups
I generated the build.xml for org.eclipse.core.tools and found that it contained the classpath (below) for use in compiling coretools.jar. I have put in line breaks and annotations to simplify things here. There are several things to notice: 1) every project has a bin dir entry. I only have about 4 source projects in my workspace. We should consider only adding these where required. In any case, the bin entries should occur with (and before) the corresponding .jar entries if they both exist. This better matches what happens at runtime. 2) the order of the entries is wrong. There does not appear to be any rhyme nor reason to the order (likely output from a hashed data structure). the entries should be in an order which corresponds to the order in the plugin.xml requires statements. Again, this matches the execution environment. 3) additional jars included in the plugin itself (e.g., tools.jar here) should be at the beginning of the path. ../org.eclipse.ui.views/bin; ../org.eclipse.core.runtime/bin; ../org.eclipse.core.runtime/runtime.jar; ../org.eclipse.ui.workbench/workbench.jar; ../org.eclipse.core.resources/resources.jar; ../org.eclipse.ui.win32/ui.jar; ../org.eclipse.core.boot/bin; ../org.eclipse.swt/ws/${ws}/swt.jar; ../org.eclipse.text/text.jar; ../org.eclipse.jface/bin; ../org.eclipse.ui.views/views.jar; ../org.eclipse.ui.workbench.texteditor/bin; ../org.eclipse.ui.editors/bin; ../org.eclipse.core.resources.win32/resources.jar; ../org.eclipse.ui.workbench/bin; ../org.eclipse.jface/jface.jar; ../org.eclipse.ui.editors/editors.jar; ../org.eclipse.ui/bin; ../org.eclipse.ui/ui.jar; ../org.eclipse.swt.win32/ws/${ws}/swt.jar; ../org.eclipse.core.resources.spysupport/spysupport.jar; ../org.eclipse.core.resources/bin; ../org.eclipse.swt/bin; ../org.eclipse.text/bin; ../org.eclipse.ui.win32/workbenchwin32.jar; ../org.eclipse.jface.text/bin; ../org.eclipse.core.boot/boot.jar; ../org.eclipse.ui.workbench.texteditor/texteditor.jar; tools.jar; ../org.eclipse.core.resources.spysupport/resources.jar; ../org.eclipse.jface.text/jfacetext.jar
More notes 4) There is an entry ../org.eclipse.core.resources.spysupport/spysupport.jar; but no corresponding bin entry. It turns out that this was the one case where I really did want a bin entry as I was working on that fragment as well so had it as class files not a jar. 5)fragment entries must occur with (but AFTER) the corresponding plugin. Again, this mimics the execution classpath. In the example here, resources/bin occurs after the spysupport.jar entry. Finally, I believe that this code worked at one point so it may be possible to track down the old code and reinstate it. Perhaps in the 1.0 timeframe?
Should investigate re-using the code in Runtime which calculates the classpath for the plug-ins.
PluginDescriptor.getPluginClassLoaderPath
This problem was also causing the eclipse build to fail. I fixed it in this case, but haven't tested yet with the PDE. The solution does not use the code proposed by DJ because it needed adaptation, whereas the fix was straightforward.
The code computing the classpath (AbstractBuildScriptGenerator::getClasspath) has been updated to reflect the requirements, and the way classpath should be computed. The code returns a classpath much closer to the one got at runtime.
It appears that the compile path is still wrong. Below is the path for org.eclipse.pde.build. Several things to note: 1) xerces comes after runtime and ant.core both of which require it. 2) jdt comes before resources (jdt requires resources) 3) strangely, the update core jar is setup to come from a different place altogether. This location exists but that jar is just data and will be deleted later. it should not be discovered (note that all the jars have copies in that same directory and they are not coming from this strange place) ../org.eclipse.core.boot/boot.jar; ../org.eclipse.core.runtime/runtime.jar; ../org.apache.ant/ant.jar; ../org.eclipse.ant.core/antsupport.jar; ../org.apache.xerces/xmlParserAPIs.jar; ../org.apache.xerces/xercesImpl.jar; ../org.eclipse.jdt.core/jdtcore.jar; ../org.eclipse.core.resources/resources.jar; ../org.eclipse.releng.builder/plugins/org.eclipse.update.core_2.1.0/updatecore.j ar">
More information. - There are several issues in getClassPath() with the ordering of when entries are added. The code is marked up with TO DO comments. It should work for now but needs more attention. - Utils.findFiles is too eager. It looks infinitely deep and finds plugins/features that are not in standard places. This could be good but the files could well be old/temporary and conflicting. For example, this behaviour is the cause of the random update.core plugin being found. I worked around this by deleting the offending files but the findFiles method should be tamed with a depth parameter.
Created attachment 3309 [details] Patch fixing the classpath problem This patch also contains a fix to modify the order in which the plugins get compiled by a feature
*** Bug 29102 has been marked as a duplicate of this bug. ***
Created attachment 3330 [details] Patch for the class AbstractBuildScriptGenerator Can not be used without the patch classpath-IXMLConstants
Created attachment 3331 [details] Patch for IXMLConstants
Comment on attachment 3309 [details] Patch fixing the classpath problem obsolete
Comment on attachment 3330 [details] Patch for the class AbstractBuildScriptGenerator obsolete
Comment on attachment 3331 [details] Patch for IXMLConstants obsolete
This is still incorrect. Note the following about the classpath generated for the org.eclipse.core.resources plugin.xml: - the resources.jar is missing - the fragments are missing (I have 4 fragments in my workspace) ../org.eclipse.core.boot/bin ../org.eclipse.core.boot/boot.jar ../org.eclipse.core.boot.nl1/bin ../org.eclipse.core.boot.nl1/nl1.jar lib/ant.jar lib/antsupport.jar ../org.eclipse.core.runtime/bin ../org.eclipse.core.runtime/runtime.jar ../org.eclipse.core.runtime.nl1/bin ../org.eclipse.core.runtime.nl1/nl1.jar ../org.apache.xerces/bin ../org.apache.xerces/xmlParserAPIs.jar ../org.apache.xerces/xercesImpl.jar
I haven't fully checked the order but it seems correct according to the famous PSP motto (Parent Self Prerequisite). The resources.jar must not appear into the list because it is the plugin for which the classpath in being computed. I don't see the reason why we should have the resource fragments jars into the classpath since we ARE compiling resources!!! The only reason I can think of is: "because this is the way it is done in the classloader", and this is incorrect in the case of the classpath (if it does not lead to errors, it is conceptually wrong). It is wrong because fragments are supposed to provide addition to a plugin, and the plugin (to which the fragments get contributed) must not know about them in advance. Moreover fragments may or not be present at runtime based on various conditions. So, for example, putting the fragments jars of the resource plugin onto the classpath for the compilation of the plugin resource would allow the resource plugin to refer to code which is only available into one of its fragment. Extra note: The tools.jar entry found in the core tools plugin classpath is wrong and is due to the inclusion of a plugin and its fragments. It must be fixed.
As of N20030212 build, the build.xml generated for org.eclipse.help.tests plug- in is still wrong and does not contain entry ../org.eclipse.help.ui.win32/bin for the org.eclipse.help.ui.win32 fragment, but it correctly contains ../org.eclipse.help.ui.win32/helpworkbenchwin32.jar Therefore I need to patch the build.xml or have an entry jars.extra.classpath=../org.eclipse.help.ui.win32/bin in the build.properties to be able to compile the test plug-in in my workspace.
This is normal since the code has not been released yet
Created attachment 3470 [details] Yet another patch
Comment #16 is generally accurate with the following clarifications: - resources.jar is not included because it is the *jar* for which the classpath is being computed. Other jars in the plugin should be included. - The tools.jar in the core tools plugin is a jar does not come from a fragment. It is a jar that is supplied by a third party and is not compiled by the build. It should be included in the path as appropriate. - Fragments for a plugin should NOT be included on the classpath for jars defined in *that* plugin. - Fragments for a plugin should be included on the classpath for jars from other fragments for *that* plugin. This allows people to have collections of cooperating fragments. They of course all need to be present at compile time and errors will likely occur at runtime if fragments are missing but that is a configuration/install issue. - Fragments for prerequisite plugins should be included on the classpath for jars in a plugin. This allows a feature to supply plugin A (which requires plugin B) and a fragment for plugin B which adds more function and is used by A. Again, this may cause runtime errors if the fragment is not present but that is a configuration/install issue.
Gadzooks!! I did not mean to make this into an enhancement. It is still critical. Changing it back...
The last patch provided (2003-02-13 11:02) implements the described behavior.
This is the classpath for the org.eclipse.core.spysupport fragment. Is this correct? I find the resources.win32/linux entries curious. ../org.eclipse.core.boot/bin; ../org.eclipse.core.boot/boot.jar; ../org.eclipse.core.boot.nl1/bin; ../org.eclipse.core.boot.nl1/nl1.jar; ../org.eclipse.core.resources/bin; ../org.eclipse.core.resources/resources.jar; ../org.eclipse.core.resources.win32/resources.jar; ../org.eclipse.core.resources.linux/resources.jar; ../org.eclipse.core.resources.nl1/bin; ../org.eclipse.core.resources.nl1/nl1.jar; ../org.apache.xerces/bin; ../org.apache.xerces/xmlParserAPIs.jar; ../org.apache.xerces/xercesImpl.jar; ../org.eclipse.core.runtime/bin; ../org.eclipse.core.runtime/runtime.jar; ../org.eclipse.core.runtime.nl1/bin; ../org.eclipse.core.runtime.nl1/nl1.jar
This entry and the resources.win32 entry are incorrect but do not cause problem since the jars does not exists. The way things work right now it would be difficult to get rid of them. The presence of these two entries is due to the code that handle the SWT case. To be precise: -When a fragment does not declare a runtime library, it is assumed that it however provides a library which name is declared into the plugin (format usually the library name is generic for example $ws$). So a classpath entry concatenating the plugin library to the fragment is added. For example the plugin swt declares $ws$/swt.jar as a library, and the swt.win32 fragment does not explicitly declares a library but provides swt.jar. So we get an entry saying : swt.win32/$ws$/swt.jar which is required since indeed the swt plugin does not actually provide a jar. To fix the problem there are several possibilities: - Having a flag in a build.properties or the plugin.xml of the plugin saying that the library are provided by the fragments (for example swt would set this flag) - Having a flag in a build.properties or in the fragment.xml of the fragment saying that the library do NOT provide libraries - Fix SWT fragments to declare their libraries into the fragment
the linux stuff looks strange but I think its ok. You have those fragments installed and there is no way to tell that it is linux only etc. What I find curious that the runtime is after xerces. Runtime should be the first thing after all of the bits for the plugin jar being built.
It is not strange, it's PSP!!! The resource plugin has xerces into its prerequisite
yes but runtime is ALWAYS the first prerequisite.
Created attachment 3507 [details] Patch for the runtime inclusion pb The code has been cleaned up.
Released to HEAD.
*** Bug 31084 has been marked as a duplicate of this bug. ***
In case some true compiler errors are reported, is the user provided with the actual compile log ?
The user get a message like "Some problem occurs, see the log files". This file which is hidden in a temp.folder in the plugin contains the compilation for the log. In the new stream, I don't know where the log file will be since PDE UI is trying to generate everything outside of the workspace.
Pascal, Just to let you know, I'm using the latest code in HEAD and there is still a bug in the classpath that you generate. Try the following: 1. Import JDT Core, all its required plug-ins, org.eclipse.core.boot, and org.apache.ant into your workspace *with* linking. 2. Check out JDT core from CVS and overwrite the binary JDT core project you imported in step 1. 3. right-click on org.eclipse.jdt.core/plugin.xml and 'Create an Ant build file'. 4. Open the build.xml file and examine the classpath used to compile jdtCompilerAdapter.jar. You will see that it contains all the entries seem correct, except for "../org.apache.ant/ant.jar". This library path does NOT exist, because we imported with linking, ie. instead, you should reference the actual physical path as you do with the other libraries in the classpath. So building JDT core if org.apache.ant has been importing with linking fails, when ant.jar is not found. 5. If you re-import org.apache.ant into your workspace *without* linking, the build completes without error, since now "../org.apache.ant/ant.jar" is actually physically there.
As Wassim's example shows it (see comment #33), this problem only occurs for plugins that are "linked". To be more precise it only occurs for linked plugins that are explicitly referenced in the extra classpath entry of the build.properties. In this value, the user specify a relative path to a plugin which we simply use as is. In the JDT case, jars.extra.classpath=../org.apache.ant/ant.jar, and we simply copy this value. Currently the only solution would be not to use links ;-) An appropriate solution requires a change in the jars.extra.classpath so that people can say that the jar they refers to is in a plugin. For example the previous entry would look like jar.extra.classpath=${PLUGIN:org.apache.ant}/ant.jar PLUGIN could also be FRAGMENT. DJ, Jeff, what do you think of that?
Wouldn't want to invent new syntax. Perhaps just use the platform URLs. The user would spec "platform:/plugin/org.apache.ant/ant.jar" (not sure I have the syntax correct but you get the idea). There may well be issues with resolving that URL correctly because it uses the registry but this is PDE and it has its own registry to represent the target install.
As you said, platform:/plugin URLs refers to the plugins at runtime. So using this kind of URL is not correct, and if I process it by myself it can then lead to misunderstanding of URLs from the user point of view. Then I decided to use platform:/resouce URLs which works fine in the case of the workspace and are more correct, since we simply want to refers to a file in the workspace. However I think these URLs will probably not work in case of the pde-build in batch mode since the plugins that are compiled are not put into the workspace (I'm correct here about this assumption?) So do we really want to use URLs?
resource URLs do not help as there is no requirement for the jars to be in the workspace (or for there to be a workspace at all). The plugin URL is not confusing (at least to me :-). In the build.properties the user is saying that they want the jar from some plugin. That statement is evaluated in the context of the plugins being built. As for whether or not you need a URL, it is not a requirement but it is a syntax that we already have. It would be better to reuse that rather than introduce another one which carries the same information. You can choose to parse it yourself the same way you would have to parse any other syntax.
Created attachment 3547 [details] Fix for the pb noted in comment #33 This patch provides support for URL in extra.classpath entries. All URLs are accepted but : platform:/resource ones since the scripts can be run outside of a workspace. An exception is indicated. The syntax for other platform's URLs is strict and must always starts with platform:/plugin/ or platform:/fragment/ and be followed by the plugin id, then the rest is free. Note that the semantic of these urls, is slightly different from the regular one in the sense that they will return the url of the plugin you are building against, and not the one you are running against. But this is not confusing ;-) Extra note: the patch has been made from AbstractBuildScriptGenerator.java
Released.
There is a new problem with classpath computation using latest ode.build code in HEAD: 1. Check out JDT core from cvs. 2. right-click on org.eclipse.jdt.core/plugin.xml -> Create Ant build file 3. You will get a MalformedURL exception and the following stack: java.net.MalformedURLException: no protocol: ../org.apache.ant/ant.jar at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at org.eclipse.pde.internal.build.AbstractBuildScriptGenerator.computeExtraPath (AbstractBuildScriptGenerator.java:242) at org.eclipse.pde.internal.build.AbstractBuildScriptGenerator.addSelf (AbstractBuildScriptGenerator.java:191) at org.eclipse.pde.internal.build.AbstractBuildScriptGenerator.getClasspath (AbstractBuildScriptGenerator.java:124) at org.eclipse.pde.internal.build.AbstractBuildScriptGenerator.generateBuildJarsTar get(AbstractBuildScriptGenerator.java:553) at org.eclipse.pde.internal.build.ModelBuildScriptGenerator.generateBuildScript (ModelBuildScriptGenerator.java:80) at org.eclipse.pde.internal.build.ModelBuildScriptGenerator.generate (ModelBuildScriptGenerator.java:61) at org.eclipse.pde.internal.ui.feature.BuildPluginAction.makeScripts (BuildPluginAction.java:210) at org.eclipse.pde.internal.ui.feature.BuildPluginAction.doBuildPlugin (BuildPluginAction.java:139) at org.eclipse.pde.internal.ui.feature.BuildPluginAction.access$0 (BuildPluginAction.java:130) at org.eclipse.pde.internal.ui.feature.BuildPluginAction$2.run (BuildPluginAction.java:53) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1588) at org.eclipse.pde.internal.ui.feature.BuildPluginAction$1.run (BuildPluginAction.java:60) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:296) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:246) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run (ProgressMonitorDialog.java:351) at org.eclipse.pde.internal.ui.feature.BuildPluginAction.run (BuildPluginAction.java:70) at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:250) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:450) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:398) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:392) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:72) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:836) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1692) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1410) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1288) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1271) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
Created attachment 3578 [details] Temporary fix until 2.2 starts This is normal, because ../org.apache.ant/ant.jar is not a valid URL. If you look at the comment #38, you will notice that the format of jar.extra.classpath has changed and that only URLs are valid. For the sake of simplicity and backward compatibility I put back the support for the old format, however the old format will produce a bogus classpath.
pde.build should accept both files and urls on the extra jars line. It is easy to detect the difference. Take an entry, try to make a URL. If it works you have a URL. If it doesn't, assume it is a file. The ability to have files at this point is effectively API and cannot be changed. It is true that in Wassim's case he has to use a URL because he is wanting to handle links. Note that bailing on with this kind of error is less than optimal. In this case it would be better to either fail with a nicer message or log a warning that an entry is being ignored and keep on going.
*** Bug 29073 has been marked as a duplicate of this bug. ***
