Community
Participate
Working Groups
I've just moved my workspace from 3.7 to 4.2M2. Plugins in the workspace that have API tooling enabled now show an error marker and the message: Execution environment references were not checked for 'plugin' because no environment descriptions are installed. It is not clear what this message means or how to correct it. I have not been able to locate it in any documentation.
You need to install the EE description from a p2 repository. Add the update site in the list of available update site: http://download.eclipse.org/eclipse/updates/3.8-I-builds Then select "Install New Software..". Check that update site. Uncheck the option "Group items by category" and type "description" in the search field. Then install all the API descriptions you want to use. Hope this help.
There is also a quickfix on that problem which will open the correct preference page. Moving this bug to doc as we can add a blurb about it somewhere.
I had to rebuild the projects, but otherwise this fixed the errors. Thanks! I presume these will be installed by default in the final version?
I'm not seeing any EE descriptions at http://download.eclipse.org/eclipse/updates/3.8-I-builds following the instructions in Comment 1. Did these move?
(In reply to comment #4) > I'm not seeing any EE descriptions at > http://download.eclipse.org/eclipse/updates/3.8-I-builds following the > instructions in Comment 1. Did these move? They should be there. The category still exists, but there are no entries currently. Probably something wrong with the integration build that will be corrected in the near future. I'll cc Kim so she is aware.
(In reply to comment #5) > (In reply to comment #4) > > I'm not seeing any EE descriptions at > > http://download.eclipse.org/eclipse/updates/3.8-I-builds following the > > instructions in Comment 1. Did these move? > > They should be there. The category still exists, but there are no entries > currently. Probably something wrong with the integration build that will be > corrected in the near future. I'll cc Kim so she is aware. Currently you can get them from http://download.eclipse.org/eclipse/updates/3.8milestones There is a bug open about them missing from the I builds. PW
Great; thanks for your help.
I'm still getting this with M5. And even after installing them I still get the error.
BTW, I'm talking about 4.2M5. I was using 3.8M4 and this workaround worked then. Haven't tried 3.8M5.
You might be seeing bug 369402 in M5 PW
(In reply to comment #9) > BTW, I'm talking about 4.2M5. I was using 3.8M4 and this workaround worked > then. Haven't tried 3.8M5. Ditto. I've just leaped into the E4 world with 4.2M5 and am seeing these issues building the CDT sources. I, too, installed the EEs as instructed with no relief.
(In reply to comment #11) > Ditto. I've just leaped into the E4 world with 4.2M5 and am seeing these issues > building the CDT sources. I, too, installed the EEs as instructed with no > relief. Select the project. Right-click>Properties>Plug-in Development>API Errors/Warnings>API Use. What do you see in the "Execution Environment Descriptions" section ? I got a case where the section was still empty even if I installed the descriptions. I had to do a restart with "-clean" to fix it.
(In reply to comment #12) > (In reply to comment #11) > > Ditto. I've just leaped into the E4 world with 4.2M5 and am seeing these issues > > building the CDT sources. I, too, installed the EEs as instructed with no > > relief. > Select the project. Right-click>Properties>Plug-in Development>API > Errors/Warnings>API Use. > What do you see in the "Execution Environment Descriptions" section ? > > I got a case where the section was still empty even if I installed the > descriptions. I had to do a restart with "-clean" to fix it. Bingo! That was it. The properties page showed no EEs installed. I relaunched with -clean and they then appear. I did a clean/rebuild and no longer get the errors. However, I go get an NPE dialog. I'll attach the exception stack trace.
Created attachment 211125 [details] NPE stack trace
(In reply to comment #14) > Created attachment 211125 [details] [diff] > NPE stack trace It is indeed possible to get a null class file. So we should add some tracing for this as I was not expecting that the class file for a superclass is not available. I suggest to log the superclass name and the component name and report true to say that the reference was validated. Once this is done, it would be good if you could try it again, so that we have an idea why the class file for the superclass was not found.
Created attachment 211131 [details] Proposed fix
(In reply to comment #15) > (In reply to comment #14) > > Created attachment 211125 [details] [diff] > > NPE stack trace > It is indeed possible to get a null class file. So we should add some tracing > for this as I was not expecting that the class file for a superclass is not > available. > I suggest to log the superclass name and the component name and report true to > say that the reference was validated. > Once this is done, it would be good if you could try it again, so that we have > an idea why the class file for the superclass was not found. Assuming this gets picked up in the next milestone, I'll go through the same steps and report back what I get.
Mike and I were discussing what we could do to 'discover' that the list of installed descriptions has changed at startup and rebuild. This would remove the need to do a clean of the workspace. The proposed solution was to store a list of the fragments installed when API tools starts up. If the list changes, we could then perform a full api tools build. I pushed a basic implementation of this to a feature branch: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/?h=cwindatt%2Fbug361660 Doing this at plug-in startup isn't perfect as the user needs to do something to startup API Tools before their markers will be cleaned. Also, I ended up storing this in preferences, which means that when switching workspaces you may get a build at each startup (but this likely is correct as the projects in each workspace may need to react to the fragment changes).
(In reply to comment #18) > Mike and I were discussing what we could do to 'discover' that the list of > installed descriptions has changed at startup and rebuild. This would remove > the need to do a clean of the workspace. > > The proposed solution was to store a list of the fragments installed when API > tools starts up. If the list changes, we could then perform a full api tools > build. > > I pushed a basic implementation of this to a feature branch: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/?h=cwindatt%2Fbug361660 > > Doing this at plug-in startup isn't perfect as the user needs to do something > to startup API Tools before their markers will be cleaned. Also, I ended up > storing this in preferences, which means that when switching workspaces you may > get a build at each startup (but this likely is correct as the projects in each > workspace may need to react to the fragment changes). The approach makes sense to me. I think it is the best solution without causing API tools to load at start up. It would be even better if we could also provide some hooks to know when EE fragments have been installed *without* a restart - i.e. the user presses "Apply Now" or "Not Now" when installing descriptions from the pref page
I have pushed both Olivier's logging fix and my build on startup fix.
Not good. I get NPEs and the bundle doesn't start: aused by: java.lang.NullPointerException at org.eclipse.pde.api.tools.internal.provisional.ApiPlugin.getListOfEEFragments(ApiPlugin.java:600) at org.eclipse.pde.api.tools.internal.provisional.ApiPlugin.checkForEEDescriptionChanges(ApiPlugin.java:532) at org.eclipse.pde.api.tools.internal.provisional.ApiPlugin.start(ApiPlugin.java:518) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) ... 106 more
Fixed in master. Platform.getFragments() returns null when there are no results instead of an empty array. The null check was removed when I moved the search to its own method.
Oh man! Again, NPE but a bit later (see stack below). And of course the builder fails. Caused by: java.lang.NullPointerException at org.eclipse.pde.api.tools.internal.provisional.ApiPlugin.checkForEEDescriptionChanges(ApiPlugin.java:556) at org.eclipse.pde.api.tools.internal.provisional.ApiPlugin.start(ApiPlugin.java:518) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
Fixed in master: 9040cf1832ea8d6f8e9643d67589871ca158ea2e
Verified in I20120224-1544.
I just installed RC4 and I'm seeing exactly the same messages I reported in the original comment.
(In reply to comment #26) > I just installed RC4 and I'm seeing exactly the same messages I reported in the > original comment. Did you install the EEs as requested in this bug?
Yes, I'm able to make the errors go away by installing the EE's, but shouldn't they be installed by default? They used to be.
(In reply to comment #28) > Yes, I'm able to make the errors go away by installing the EE's, but shouldn't > they be installed by default? They used to be. The EE's are not installed by default, AFAIK they never have been. The default workspace setting for 'Reference not defined in specified EE' is Ignore so the problems would not have been reported. Returning to FIXED.
Returning to VERIFIED. If you still believe you are experiencing a bug, please open a new report or clone this bug.
Well, prior to 4.2, I've never installed an EE. So something has changed between 3.x and 4.2 that is going to confuse anyone that is using API tooling.
(In reply to comment #31) > Well, prior to 4.2, I've never installed an EE. So something has changed > between 3.x and 4.2 that is going to confuse anyone that is using API > tooling. Yes, the error is new, but it should only appear if in your workspace or project properties, the option to check the API reference has been changed from the default 'Ignore' to something else. If that's not the case, then please open a new bug, with steps to reproduce the problem.
Yes, it's set to Error. I can't imagine I changed it, but I can't say for certain I didn't. I doubt opening a bug would achieve much under these circumstances. Thanks!
(In reply to comment #33) > Yes, it's set to Error. I can't imagine I changed it, but I can't say for > certain I didn't. I believe you :-). That specific problem report is new and set to 'Error' by default. What I wanted to explain is, that the error should only be reported if either the project or the workspace has the following option changed from 'Ignore' to something else: Plug-in Development > API Errors/Warnings Reference not defined in specified execution environment: ==> If you have that set to 'Ignore' and get the error reported, then that's not what we intended and would deserve a bug report, hopefully with steps to reproduce out of a new workspace.
