Community
Participate
Working Groups
Related to bug 159107. Or rather the motivation for creating that report. build i0926-0935 and others. We commonly get into a weird state where imported packages aren't being resolved. They seem to be happening in projects that have class folders and no source. For instance with: dev.eclipse.org/cvsroot/eclipse/equinox-incubator//org.apache.commons.httpclient We had a project in our workspace (source) which imported packages from this project and the types could not resolve. Sometimes removing the ImportPackage statements from the manifest and creating bundle dependancies is a work around. Another work around is to export the bundle to disk, delete the project from your workspace, then import the plug-in from disk as a binary project. Of course this doesn't help if you want to modify the source code for the projects.
For this example, assume that we have the following setup: Project FOO exports package foo and contains class files (the project folder is a class file folder). Project BAR imports foo but cannot see the classes. 1). when I click on the project properties for BAR and I look at the Java Build Path, FOO is listed as a project dependancy. If I expand the list I can see the appropriate package and the access restrictions are fine. 2). if I do an Open Type... the classes from package foo are NOT listed in the dialog. Will come up with a more concrete example soon... Adding Frederic to CC in case it is a jdt issue.
build n0929-0010 - new workspace - file -> import -> cvs -> project from cvs - create new anonymous pserver connection to dev.eclipse.org /cvsroot/eclipse - check out org.apache.commons.codec - create a new plug-in project - add org.apache.commons.codec to the package imports in the manifest - create the following new method in the Activator class: public void foo() throws Exception { throw new DecoderException(); } Note that the DecoderException class cannot be resolved.
sorry, the org.apache.commons.codec project is in the /equinox-incubator folder of the /eclipse repository.
The batch compiler seems to work fine. So the problem might come from the builder. Moving to JDT/Core since the access rules set by PDE/Build seem to be fine.
The entry in the pde container that corresponds to the project P (with the proper access rules) is considered to be a classpath entry with the following properties: P[CPE_LIBRARY][K_BINARY][isExported:false] 1) This entry is ignored inside the name envionment of the builder. See org.eclipse.jdt.internal.core.builder.NameEnvironment#computeClasspathLocations(...) For entry that are a CPE_PROJECT, it only considers the CPE_SOURCE entries. And this is not the case here. 2) The reconciler is also broken because the JavaSearchScope doesn't consider this entry as well. See org.eclipse.jdt.internal.core.search.JavaSearchScope#void add(JavaProject, IPath, int, HashSet, IClasspathEntry) throws JavaModelException. line 109. if (!entry.isExported() && entry.getEntryKind() != IClasspathEntry.CPE_SOURCE) continue; This is true for this entry so it is ignored. Why only CPE_SOURCE entries are considered in both cases ? This means that project that acts as class folders are never considered when referenced through import packages. Assign to Maxime to fix first the issue in the builder.
Created attachment 51431 [details] Zip that contains two projects to reproduce this problem
Using the test cases of comment #2 and comment #6, I reached in both cases to the following conclusion: marking the class folder (respectively org.apache.commons.codec and P2/src) as exported in the Java build path of the target project allowed the dependent project to compile OK. (Note that it was not marked as such before I did it, and the error showed up as expected.) Using I20060922-0010 for this test, will retry with latest I-build. This behavior is consistent with comment #5 in that, at the point where we examine the P[CPE_LIBRARY][K_BINARY][isExported:false] entry, we are in the target project. If it does not export the library, then dependent projects do not see it. I haven't digged deeper into comment #1, so please reopen if I missed something. I will reopen myself if I20061003-0800 misbehaves.
I20061003-0800 behaves OK. Added MultiProjectTests #100 and 101 to illustrate the current behavior.
I am still able to reproduce this problem with build i1003. - extract attached zip to file-system - open new workspace - File -> import -> existing projects into workspace - point to folder where zip was extracted - import both projects Note the compile error: "p cannot be resolved".
Agreed. It is exactly what I did first. But then if you mark the class folder P of project P as exported, the error vanishes (incorrectly suggested to export P2/src in comment 7 - sorry for that). So, as far as classpath resolution is concerned, I'd contend that everything is OK. Having thought it through since this morning, I understand that the net effect may not be what you'd want to achieve. The way in which P2 dependencies shows package p may lead to the conclusion that the target project (P) is rather irrelevant in the discussion. (The interface states: 'Specify packages on which this plug-in depends without explicitly identifying their originating plug-in'.) Still, I'd rather stand behind the rule that a non exported package is not visible to anyone else in the workspace for one thing - as opposed to considering the exported property for explicit inter-project dependencies only - and I'd suggest that the desired effect calls for a different paradigm for a second thing - for now, it is using a project classpath entry to reach for the library entry matching the class folder, whereas the seamingly disconnected view of such packages suggests that an indirection be considered at a workspace level. Philippe, what do you think?
Exporting the entry fixed this case, but the reconciler is still broken. It seems that the java search scope should use the expanded classpath instead of the resolved classpath. Frederic, any comment on this?
Moving to Frédéric for consideration of comment #11.
(In reply to comment #11) > Exporting the entry fixed this case, but the reconciler is still broken. > It seems that the java search scope should use the expanded classpath instead > of the resolved classpath. > Frederic, any comment on this? > Unfortunately I had no time to look at this :-( The bad news is that I can reproduce the problem using 3.3.2, but the good news is that it has been fixed during the 3.4 dvpt as I cannot reproduce using 3.4.0 As I have no time to search what was the change which magically fixes this issue, I close this bug as WORKSFORME target 3.4...
(In reply to comment #13) > it has been fixed during the 3.4 dvpt as I cannot reproduce using 3.4.0 > Verified using build I20080617-2000
