Community
Participate
Working Groups
I just wasted *a lot* of time trying to debug my plugin, only to realize that I wasn't running the code I thought I was due to some "out of sync" error on one of my plugins. How I got in this state was approximately: - had binary projects imported - checked out projects from CVS overtop - self hosting debug I think during checkout one had failed somehow -- I didn't have any classes. But I thought since I was actually checking out a branch I had just picked an empty one. So I repeated and got content. Not sure, that was yesterday. All the time, it turned out that that project had some PDE "Out of sync" error. After much failed debugging I was finally able to show that my plugin.xml wasn't even being used, my old one was still. Given that, we thought to look in run configuration. Its completely unacceptable that the user should be able to execute self hosting if the code they are looking at in the development environment is somehow not the code they are executing (unless they took advanced steps to do so). At least if there is an error that PDE is aware of they should: 1. warn you when launching 2. write something in the .log
Created attachment 1238 [details] screen shot showing PDE error
Another issue is that I have no idea how I am supposed to make the PluginManager be in sync. I tried deleting and reloading my project but the error remains.
PDE has a dual-step update in the model manager: when there is a delta for the manifest file, it tries to read it with force==false. If it receives a core exception, it reads it with 'force==true' and sets 'outOfSync' bit. This indicates that it was able to read the contents but it had to force its way while doing that, and you are better off refreshing or otherwise clearing the situation. You said that the checkout failed somehow and you didn't have any classes. Before PDE gives you logs or warnings about it, shouldn't import itself warn you about the failure? Is it possible that you had out-of-sync resoures that caused checkout to fail? When you have the workspace out-of-sync with the file system, you will get funny results because you operate on workspace data but the run-time workbench takes information from the file system. This is how you could run different things that you think you see in the workspace. Out-of-sync resources are a grey area in Eclipse. Editors and other tools sort of tolerate them, but you can get into many funny situations if you do not fix them quickly. I don't know how to handle this particular problem, except maybe add the warning on launching you mentioned.
Unfortunately I can't add more details to how I might've gotten into the situation. I am not sure if the steps I mentioned were at all related (I had to be somewhere at a certain time and couldn't investigate). That aside, the bigger issue is that I wasn't warned I was in this state.
- I took a new workspace - loaded in my source projects - loaded in remaining binary (by having the wizard select all projects then inverted selection). I am still getting the warning in the launcher
Maybe there is something wrong with your source projects. I did the same today with my source project and I don't see the errors. Could you send me the list of project to try it out on my end?
F3 candidate.
Import the attached Team project set, then add everything else from F2. Should work if you get at it soon (before the contents of those streams change).
Created attachment 1247 [details] team project set
Well this just gets stranger as you go. Apparently my plugin.xml has errors - when I try to switch to any view other than the source xml one I get: Title: Plugin Manifest Editor Message: The source page has errors. Other pages cannot be used until these errors are corrected. I have no error tasks, so I have no idea where the error is that its complaining about (another bug). The file you want is revision 1.16.4.2 of org.eclipse.team.cvs.core/plugin.xml. I mention this in case I commit a corrected plugin.xml to the branch. Taking out what I assume are the offending lines ( <!-- *************** Repository Provider **************** --> <extension point="org.eclipse.team.core.repository"> <repository id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"/> </extension> ) results in over 1600 build errors because the .classpath gets regenerated wrong. The lines above that were removed have no relationship to the .classpath contents. Reconstructing the file by taking one that worked, and adding those lines in, gets me going. I will attach my current plugin.xml and resulting bogus generated .classpath. I was however able to get 1.16 of plugin.xml (where I started from), reapply the changes, and get it to not have an error anymore. But I had to let PDE regen my plugin.xml the way *it* wants it. The change was: <repository id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"/> became <repository class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider" id="org.eclipse.team.cvs.core.cvsnature"> </repository> Note the change from "/>" to "</repository>".
Created attachment 1248 [details] plugin.xml it didn't like
Created attachment 1249 [details] resulting mangled .classpath
This report flags several problems: 1) Screen shot reveals NL substitution error (should be "(out of sync)"). Fixed. 2) Lack of error reporting: partially caused by the project not having PDE nature. 3) Lack of error reporting on launch. PDE is now warning the user that some plug-ins are out of sync or otherwise broken (which is often the case when model (re)load fails due to syntax errors in the manifest). PDE already handles error reporting using the builder. Builder or not, the launcher is now warning about 'broken' plug-ins. In addition, if you somehow go past the dialog or launch from the shortcut, you will get an error dialog listing you the plug-ins that have errors. The dialog will allow you to continue launch but warn you that run-time workbench will most likely disable these plug-ins on startup. Launcher has also been fixed to tolerate broken plug-ins and try to create the plug-in path file with them. I think that this is the best we can do for 2.0.
