| Access restriction: The field 'XXX' is not API (restriction on required lib XXX) [message #1719063] |
Mon, 04 January 2016 14:46  |
Eclipse User |
|
|
|
Hello and a happy new year to everybody!
I have a problem with the dependencies of my Scout project. I imported it with the wizard to a fresh version of Eclipse Mars for Scout Developers on a windows machine.
I have those dependency problems only in the mobile and the swt plugin. The server for example can be started.
I played around with the build path settings and the manifest files of the projects, but couldn't solve the problems. All access restriction problems have to do with scout-related packages.
One of 120 error descriptions as example:
Access restriction: The field 'ContributionCommand.Continue' is not API (restriction on required library 'E:\Workspaces\EclipseProjects\Scout\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.scout.rt.client_5.0.100.20150902-1531.jar')
I'm wondering why it tries to access the resource in the workspace and not in the eclipse directory...
Best regards,
Jannik
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Access restriction: The field 'XXX' is not API (restriction on required lib XXX) [message #1723069 is a reply to message #1719063] |
Thu, 11 February 2016 06:14  |
| Eclipse User |
|
|
|
To hold this thread up to date and maybe get some additional help:
I sent Matthias my workspace and he could reproduce the same restriction erros on his system. Unlike me he somehow managed to get the project running by creating a scout project from scratch and moving over my workspace content.
At this point I want to thank him again for his efforts!
Unfortunately this hasn't helped me so far. No matter what I did, there where always serveral restriction access errors.
I tried the common solutions I found for those kinds of errors like readding the JRE library, changing the order of the plugin dependencies, set forbidden reference signal from error to warning, setup new projects in new workspaces, tried various target definitions etc., but the right combination was obviously not among them.
I promised myself the most of getting the workspace that Matthias sent me running, because I know it already worked on his system.
When I start a eclipse scout instance in this workspace the target definition doesn't work, because the "scout_rap_target" configured there points to a directory on Matthias' system. To get rid of it I changed it to point to the folder "rap_target" in my eclipse installation directory to look like this:
Does anyone know, what to do next? I don't want to mess this workspace up too by doing something I'm not completely familiar with. So I hope for some advice. I have other workspaces and projects I can tinker with 
[Updated on: Thu, 11 February 2016 06:16] by Moderator |
|
|
|
|
|
|
|
|
| Re: Access restriction: The field 'XXX' is not API (restriction on required lib XXX) [message #1723431 is a reply to message #1723162] |
Mon, 15 February 2016 10:51 |
| Eclipse User |
|
|
|
With Matthias' help I found out, why I couldn't get his workspace running on my system. As you see on one of the previous screenshots, the problem was that the 'eclipse_home' target couldn't resolve any plugins, although the directory it pointed to was fine.
I found out that in the target file it was declared as a location of the type 'Directory' instead of 'Profile'.
So I deleted and readded it with the target editor via
'Add...'->select 'Installation'->'Next >'->'Variables...'->select 'eclipse_home'->'OK'->'Finish'.
This should produce the location entry
<location path="${eclipse_home}" type="Profile"/>
in the traget file.
After these fixes the workspace was running without errors. My old workspace still doesn't work with the same target file and the same eclipse installation. I don't know what's going wrong.
It would be great If I could get my old workspace running again, as there is a git repository and some other documents which I would have to carefully move over to the new workspace potentially causing new errors.
Matthias recommended to spend not too much time for the target issues and trying to migrate to Scout Neon instead. I'm not sure whether this would be sufficient for me, as I rely on a (standalone ) desktop build of my application. My latest information is that there will no longer be a desktop renderer in Scout Neon.
[Updated on: Mon, 15 February 2016 11:45] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.09596 seconds
Home