Home » Eclipse Projects » Eclipse Platform » What on earth is causing "Type Foo is not accessible due to restriction on required project bar
| What on earth is causing "Type Foo is not accessible due to restriction on required project bar [message #306599] |
Wed, 02 August 2006 11:52  |
Eclipse User |
|
|
|
R3.1.2, WinXP
Normally when I add a new package to a plugin, I need also to add it to the MANIFEST.MF (runtime
tab), and immediately all is fine. Just now however, adding an otherwise totally ordinary package
caused the error "Type Foo is not accessible due to restriction on required project bar.bar.bar" on
every class that imports a class Foo in the new package. What hidden Eclipse setting is causing
this? (I've tried rebuild all and suchlike.)
thanks,
Paul
|
|
| | | |
| Re: What on earth is causing "Type Foo is not accessible due to restriction on required project [message #306623 is a reply to message #306620] |
Wed, 02 August 2006 19:27  |
| Eclipse User |
|
|
|
Walter Harley wrote:
>
> Paul, can you be more specific about the details of your case? E.g., post
> the contents of your manifest.mf? For instance, it's unclear from your
> initial posting what "bar.bar.bar" is - I don't know whether that's actually
> a package in your project or not, I don't know whether that's the package
> that Foo is contained in, I don't know the name of the project. I think
> more detail will help people give you a better answer.
>
Well, I have quite a few plugins, somewhat complexly-related. But the basic situation involves the
main plugin, com.mun.ist.main, and a plugin on which main depends, com.mun.ist.service. The
MANIFEST.MF of main includes:
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.core.expressions,
org.eclipse.ui,
org.eclipse.ui.forms,
com.mun.ist.service,
...
And the MANIFEST.MF of service includes:
Export-Package: .,
com.mun.ist.first.third.party.jar.code,
com.mun.ist.service,
com.mun.ist.service.fails,
com.mun.ist.service.works,
com.mun.ist.some.other.third.party.jar.code,
...
When I added com.mun.ist.service.works (the package) I made sure to add that package to
service/MANIFEST.MF, and all was fine. Time passed, bits changed; I needed to add
com.mun.ist.service.fails, and did so, and added it to service/MANIFEST.MF (after, of course, adding
a few new classes).
I then took some other classes, call them Foo and Bar, both of which were imported by the plugin
"main", and *MOVED* them from com.mun.ist.service down into com.mun.ist.service.fails (using the
refactoring tool); the imports were correctly adjusted in those classes of "main" that imported Foo
and/or Bar.
But I also got the error I mentioned. Now, truly weirdly, when I redo the operation (after having
shut down and restarted Eclipse), all happens as I expected it would ... and no error.
Go figure, eh?
Paul
|
|
|
| Re: What on earth is causing "Type Foo is not accessible due to restriction on required project [message #306624 is a reply to message #306623] |
Wed, 02 August 2006 20:55 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Paul Keyser" <rolarenfan@earthlink.net> wrote in message
news:earcdc$ard$1@utils.eclipse.org...
>
> But I also got the error I mentioned. Now, truly weirdly, when I redo the
> operation (after having shut down and restarted Eclipse), all happens as I
> expected it would ... and no error.
It seems that Eclipse caches some information about classloading from
plug-ins; I have never looked into the details, but I have found that at
times classes that "I know are there" in a deployed instance (including even
a debug runtime instance) don't get successfully resolved until I start
Eclipse with -clean. I wish I could be more specific about exactly what is
cached when and how to clear it, but I don't know the answers.
When in doubt reboot...
|
|
|
Goto Forum:
Current Time: Thu Jul 17 05:36:20 EDT 2025
Powered by FUDForum. Page generated in 0.12727 seconds |
Home