Community
Participate
Working Groups
At development time I have a plug-in that is a shell for some jars. It contains a manifest and a few other files but not the jars. When I load this project into my workspace, I get errors on the manifest because the package can not be found and this is normal. So far so good. Now when I add into my project the jars containing the necessary packages, something must be going wrong since the PDE does not notice the presence of the jars and therefore keep showing errors on my manifest. For an example of what I'm talking about, please load the project equinox-incubator/provisioning/com.thoughtworks.xstream, build (if your not in autobuild), run the fetch-lib.xml, build again. This problem is particularly annoying since it makes people's life willing to play around with the provisioning work a real hell.
do you also add the JARs to your Bundle-Classpath? How are the JARs added? do they make it into the .classpath file or are they just physically there? they have to be on the .classpath to be indexed by JDT and then detected by PDE.
>This problem is particularly annoying since it makes people's life willing to >play around with the provisioning work a real hell. Pascal is already blaming all the provisioning problems on PDE ;) Finger pointing is not attractive.
The jars are being downloaded into the project by running the fetch-lib.xml. Actually this script downloads an archive, extracts two files out of it into a well known path (xstream-1.2.1/lib) and finally calls refresh on the project so that the jars become visible to the resource tree. Given that the bundle-classpath contains the appropriate entry (pointing at the jar in the xstream folder), I was hoping it would be enough to refresh the content of the project. Btw I'm using I20070313-1051.
Pascal, nothing will happen to the JAR unless JDT recognizes them (ie. they get added to the .classpath). You won't be able to do anything on them (e.g. Open Type, etc.) and they will not be recognized by PDE when validating presence of packages. The problem goes away, of course, when you do a PDE Tools > Update Classpath, because PDE will then add them to the classpath. I suggest crafting the .classpath to include references to these JARs.
The .classpath already contains the right entries. Something weird I've noticed: this morning while trying to reproduce the problem, I've been able to get rid of the red X's when I only had xstream loaded, however if I have all the other projects from the provisioning loaded the problem still occurs. To get all the projects, simply get the equinox-incubator/provisioning/org.eclipse.equinox.prov.releng and then load the psf file included.
Moving to JDT/Core for investigation.
Pascal - Is this only affecting provisionning ? i.e. what is the timeframe for it ?
Yes currently only the provisioning effort is annoyed because we provide a script to automatically put a jar into a project. It would be great if this could be addressed for 3.3M7. If you can't, that's not a problem, but I thin it does deserve a fix for 3.3.
seems like others would be affected in general though perhaps not in a widespread way.
indeed, I suspect this is hitting me quite hard now. I exported one of my bundles and added it to the target (deleted it from the workspace) in an attempt to work around the issue at hand here. Now nothing I do seems to help. The classpath container shows that (in my case) the xstream bundle and packages are there and accessible yet the compiler is unable to see them and I get a mess of errors. I totally agree with the P1 prioritization and M7 timing
Created attachment 63362 [details] Proposed fix and regression test Fix consists in always looking at the roots (inside the folder being added) if the container is not a project.
Fix and test released for 3.3M7 in HEAD.
Feels like a good candidate for 3.2 maintenance backport.
As per Olivier's suggestion, I rebuilt jdt.core from HEAD and I confirm that the patch fixes my particular problem.
Thanks for the confirmation Pascal.
Verified for 3.3 M7
