Summary: | Access rule has no effect | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Yen Lu <yenlu> | ||||||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | major | ||||||||||
Priority: | P3 | CC: | aniefer, philippe_mulet | ||||||||
Version: | 3.1 | ||||||||||
Target Milestone: | 3.2 RC3 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Yen Lu
2005-08-10 10:45:23 EDT
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 |