Community
Participate
Working Groups
When setting inclusion/exclustion patters on a project classpath entry, these filters must only be applied to the project's own package fragment roots. Any other roots (libararies/projects) referenced via this plugin project's classpath container must be exempted. Two usage scenarios: 1. Create a plugin project 'com.example.xyz' with an RCP mail template. 2. import org.eclipse.ui into your workspace as source. 3. go to the plugin.xml of org.eclipse.ui and remove the <export name="*"/> from the <runtime> element. Save. When recomputing the classpath of com.example.xyz, the exclusion pattern on the org.eclipse.ui project classpath entry would be **/*. However, this currently excludes swt.jar and other libraries reexported to com.example.xyz in org.eclipse.ui's pde container. Scenario 2: Exactly as scenario 1, except that step 2 is: Import org.eclipse and all its pre-requisites into the workspace. The result here is the same, since the **/* is applied to the org.eclipse.swt project which org.eclipse.ui reexports.
To clarify. Usage of access restrictions is not including/excluding from the classpath. It is only trying to discourage direct references. The nuance comes from the fact that restricted types are still available to tooling, if needed, i.e. construct type hierarchies etc... We are considering allowing to avoid restriction concatenation when tagging project with such. We will keep propagation on containers, as a container doesn't provide any local contents only reexported one, so implicitly tagging a container with some restrictions would be meaningless if not propagated (i.e. if not interested, simply do not tag the container).
Jerome, if/when you would like to test your code changes against a restriction- enabled PDE, let me know.
Added API JavaCore#newProject(..., combineAccessRestrictions, ...) to create a project entry controlling how access restrictions are combined. In your case pass it false to not combine the access restrictions of the reexported entries. Added tests ClasspathTests#testCombineAccessRestrictions1 to 5 and RecocilerTests#testAccessRestriction3 and testAccessRestriction4. Wassim, I will send you a preview asap.
Unfortunately, with the new code, scenarios, that used to work, no longer work. Par exemple, I create a new RCP mail plugin project template (com.example.xyz) I then import org.eclipse.ui as source. Upon importing org.eclipse.ui, the classpath of com.example.xyz will now contain reference to project org.eclipse.ui. I create the classpath entry as follows: JavaCore.newProjectEntry( project.getFullPath(), inclusionPatterns, exclusionPatterns, false, new IClasspathAttribute[0], isExported); where inclusionPatterns == new IPath[] {new Path("org/eclipse/ui/internal/*")} and exclusionPatterns = new IPath[0] The result is that com.example.xyz does not compile as it no longer sees anything reexported by org.eclipse.ui.
It looks like you're only allowing access the org/eclipse/ui/internal/* packages from org.eclipse.ui. Is this intended ? In this case I would expect errors in com.example.xyz for code that needs the api of org.eclipse.ui.
org.eclipse.ui is a facade plugin which contains only one package (org.eclipse.ui.internal) and it reexports its entire library, so the restriction is fine.
Can you please give me a patch of your plugin so that I can recreate the problem ?
The code is in HEAD. The changes are strictly in pde.core, but you also need to check out pde.ui and pde.build. The whole logic is in ClasspathUtilCore in pde.core. To turn on access restrictions, there is a static member variable in ClasspathUtilCore called ENABLE_RESTRICTIONS. It is set to false by default, just set it to true.
I checked out the PDE projects from HEAD, but I cannot see how to create an RCP mail template. Can you please give details steps to reproduce the problem ? (keep in mind that I don't know anything about PDE)
The RCP Mail template is a good template because it references a lot of UI classes, so you will see a lot of red X's if anything goes wrong. How to create an RCP Mail template: 1. File > New > Project > New Plugin Project. 2. Enter com.example.xyz as project name. next. 4. In the Rich Client Application section, select YES. Accept all other defaults on that page. Next. 3. Click on the RCP mail template. Press Finish.
On step 3, after I save, I don't get any error.
you would, if you were like me and raised the severity level of access restrictions to ERROR :-) Also, did you remember to turn on the ENABLE_RESTRICTIONS flag in ClasspathUtilCore before launching?
you don't even have to modify the plugin.xml of org.eclipse.ui to see the errors (that's a later test case). They will now appear right after you import the org.eclipse.ui plugin.
Fixed ClasspathEntry#combineWith(IClassspathEntry) to use the receiver's accessible/nonAccessible files (instead of the referring entry's accessible/nonAccessible files). Updated ReconcilerTests#testAccessRestriction3 and testAccessRestriction4 (that had it backward)
I am having troubles with references to projects that do not contain source (eg. binary projects). To be able to test this scenario, you need the latest pde.core, pde.ui and pde.build from HEAD and you have to set the static member variable ENABLE_RESTRICTIONS in ClasspathUtilCore to true. 1. Create an RCP mail template project (com.example.xyz) as per comment 10. Everything will compile fine. 2. Import the plugin 'org.eclipse.ui.workbench' as binary WITHOUT links. 3. Observe how the com.example.xyz plugin now has errors due to access violations. The inclusion pattern is **/*. No exclusion pattern. The same scenario works (with the same inclusion/exclustion patterns) if I had imported org.eclipse.ui.workbench as source. Is there a bug here when dealing with projects whose code is in JARs or is there a problem with my inclusion pattern? Another thing that I could not do is the following: Suppose plugin org.eclipse.ui.workbench has two source folders (src1 and src2). Is it possible for plugin com.example.xyz to include just src1? I tried an inclusion pattern like src1/** (as per the javadoc) on the project classpath entry, but it did not work. everything was excluded from com.example.xyz.
False alarm on the binary project thing. it works fine. I was running with old code. I would still like an answer though to the multiple source folders question.
Wassim, re-reading this bug I see that you always talked about inclusion/exclusion patterns when you should have said accessible files/non accessible files patterns. Yes this has changed between since M5. Please see the JDT Core build notes for more details (especially the February 22nd 2005 entry). So to answer your question, it is not possible to set an accessible files/non accesible files pattern on a per source folder basis. What you tried is not conform to the spec (see IClasspathEntry#getExclusionPatterns(): "patterns allow specified portions of the resource tree rooted at this source entry's path to be filtered out").
We do not want to preclude from evolving into a direction where individual source folders could carry their own restrictions, and this explains the split in between inclusion/exclusion filters vs. accessible/inaccessible filters. But this evolution is not targeted for 3.1; and would be part of some support of classpath per source folder (along with options per source folders).
Verified in I20050330-0500
