Community
Participate
Working Groups
Consider the following relationship between 4 plugins: u <- v <- w where v depends on u and w depends on v Also: v <- x and w <- x In the u plugin, I define a base class: package foo; public class Base { public u.MyObject execute() { return null; } } The MyObject class is just: package u; public class MyObject {} The v plugin contains only the dependency on plugin u and no source code. Plugin w contains a dependency on v and the following source: package foo; public class Base { public w.MyObject execute() { return null; } } with: package w; public class MyObject {} In x, there is one source file: package x; public class Derived extends foo.Base { public w.MyObject execute() { return null; } } If you generate an ant build file for plugin x and execute it, you'll get: [mkdir] Created dir: F:\astk\eclipse\workspace\x\temp.folder\@dot.bin [javac] Compiling 1 source file to F:\astk\eclipse\workspace\x\temp.folder\@dot.bin [javac] ---------- [javac] 1. ERROR in F:\astk\eclipse\workspace\x\src\x\Derived.java [javac] (at line 7) [javac] public MyObject execute() [javac] ^^^^^^^^^ [javac] The return type is incompatible with Base.execute() [javac] ---------- [javac] 1 problem (1 error) [javac] Compilation failed. Compiler errors are available in F:\astk\eclipse\workspace\x\temp.folder\@dot.bin.log [javac] Compile failed; see the compiler error output for details. [copy] Copying 1 file to F:\astk\eclipse\workspace\x\@dot [delete] Deleting directory F:\astk\eclipse\workspace\x\temp.folder\@dot.bin Looking at build.xml, it creates the following <pathelement> entries for the classpath: <pathelement path="../v/bin/"/> <pathelement path="../v/@dot"/> <pathelement path="../u/bin/"/> <pathelement path="../u/@dot"/> <pathelement path="../w/bin/"/> <pathelement path="../w/@dot"/> This means that u's Base class is used to compile Derived rather than w's. This is inconsistent with the workbench's behavior. Is there any reason why u even needs to be on the classpath? I will attach the plugin projects and the generated build.xml.
Created attachment 25974 [details] Plugin projects
Is anyone going to look into this?
u gets on x compile path because x requires v which requires u. Deleting v from x or making w first on the prereq list would workaround the problem. The more fundamental problem is that pde build does not realize that u does not export classes and it does not use access rules.
need to verify that this is fixed.
I lowered the severity to normal since there is a simple workaround (reorder the dependencies so that w is before v) In 3.2 PDE.Build now specifies access rules for the classpath. (Regenerate the build.xml in x by doing PDE Tools->Create Ant Build File on the manifest). In this case we give Forbiden keep looking (?**/*) for the classpath elements from u, so the compiler should keep looking and find the classes from w which has an accessible rule. Even with the access rule we seem to still be getting the class from u, is this a problem with the batch compiler?
I still feel this problem is major at the very least. The workaround cannot be applied in our case since the dependencies are specified in third party code.
I'll investigate it to narrow it down.
The bug comes from the fact that the access rules are not passed to the batch compiler in this case. Once I manually set the access rules on the classpath entries, it compiles fine. So the bug comes from the ant adapter. I'll keep looking. Philippe, This might be a candidate for RC2.
This is due to a mismatch between the path before the access rule in the @file on the classpath and the path inside the classpath. When we get the classpath inside ant, the trailing '\' or '/' has been removed. But inside the access rule file it is still there. Therefore when we try to match the access rule with the right classpath entry using pathElements[i].endsWith(rules[j]), it never matches. And we end up setting no access rules at all. path element = D:\eclipse\workspaces\test106631\v\bin Current rule = v\bin\ Current rule = v\@dot Current rule = u\bin\ Current rule = u\@dot Current rule = w\bin\ Current rule = w\@dot The same for other entries. Andrew, we have to make sure that both pathes are consistent. Can you talk about this tomorrow ?
I believe the fix should go inside the ant adapter since PDE cannot rely on what is done by ant or not. PDE provides consistent information to the ant javac task, but before the ant adatper is called the trailing slashes inside the folder names are removed by ant. The matching inside the ant adapter to match the rules with the classpath entries must be resilient to this kind of modifications. I propose a patch that checks if rule ends with File.separator and if the pathElement ends with File.separator. Both checks need to be done because we cannot make any assumption on the last character of the rule or the path element.
Created attachment 39607 [details] Proposed fix With this patch, the given test compiles fine. Andrew, Could you please review it?
I took a look, and the only thing I see is that I think the comparison should be case-sensitive and you have ignoreCase=true in the regionMatches calls. I will do some more tests tomorrow.
Created attachment 39611 [details] New patch New patch case sensitive
+1. New patch is good, I haven't found any other problems.
+1 for release in RC3
+1 for 3.2RC3
Sonia got a patch to run a test build with this fix.
Test build was successful. Fixed and released in HEAD.
In order to verify, please use the attached test case.
Verified using N20060503-0010 for 3.2RC3
Double-checked using N20060504-0010 + JDT/Core v_663
