Community
Participate
Working Groups
build I20050512-1200 - OSGi, Runtime, SWT, JFace, UI, Text loaded from head - open type on AbstractTextEditor - at start of createPartContro method, type: PartSite<Ctrl+Space> - it has no effect in the editor, but the status line flashes in red: Access restriction: The type SerializableCompatibility is not accessible due to restriction on required project org.eclipse.swt The type name doesn't seem to matter. "abcd" has the same effect. I notice that org.eclipse.ui.workbench.texteditor's classpath has an access rule forbidding **/internal/** refs.
Nick, that is why we asked people to remove all those "arbitrary" restrictions from the .classpath of their plugin projects. Let PDE tell JDT what is restricted and what is not.
The message is still spurious. It's talking about a class and a plug-in that have nothing to do with what I was doing at the time. Also, the rule lets Text say "I don't want to refer to internals from anyone.", regardless of what the prerequisites' export rules are.
The org.eclipse.ui.workbench.texteditor/.classpath (rev. 1.8, 12.12.2005) looks like this: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> Wassim, I am a bit puzzled. If there is some "arbitrary" internal restriction then this seems obviously be generated by PDE. Also note that I remove the internal restrictions on all other Text plug-ins. Nick, before Wassim starts to investigate/comment: might it be that you did not have the code from HEAD but maybe checked out before I released the stuff yesterday? Another problem here is the build path UI: it lets me add my own 'internal' restrictions without giving any hint that PDE computed its own: the access rule entry on the build path page reads: 'Access rules: (No restrictions)'. Martin, this should be addressed. Shipping like this is very confusing.
The offending message in status bar comes from JDT/Core, we should investigate it as I agree it doesn't seem to make much sense. David - pls ensure we have a bug for this. I also heard Martin saying he'd reveal restrictions when expanding containers in buildpath wizard.
re comment 3: I was going by Nick's observation that the .classpath file had an explicit restriction to forbid **/internal/** which several other plugins had and we asked them to remove. That is what I refer to as 'arbitrary' (i.e. not enforced by the PDE container implementation), but your .classpath seems clean. For the build path UI, ideally, we should not allow anybody to modify the container in any way (ie. the Edit...) button should be disabled. But I think this is out of the question for 3.1, as one solution may require at minimum the addition of a boolean attribute on the classpath container extension point to mark it as read-only.
Dani's assumption is correct: I hadn't sync'ed, and still had rev 1.7 of the .classpath loaded, which still had the access rule. <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry excluding="**/internal/**" kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath>
>For the build path UI, ideally, we should not allow anybody to modify the >container in any way (ie. the Edit...) button should be disabled. But I think >this is out of the question for 3.1 It would be good to address this for 3.1. A must do is to show that there are some restrictions.
Martin has fixed the problem on the build-path UI side: access restrictions for plug-ins are no longer editable. Moving to core for the status line issue.
BTW: Martin added code that now shows the access restrictions that get generated from PDE.
Status line problem: Fixed and test added CompletionTests#testCompletionWithProblem1() Status line content is the nearest problem of the completion position. But CompletionEngine did not check if the problem is in the same compilation unit of the completion.
Verified on build I20050527-0010.
