Summary: | No obvious indication of "out of sync", wasted time debugging wrong thing | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] PDE | Reporter: | Kevin McGuire <Kevin_McGuire> | ||||||||||
Component: | UI | Assignee: | Dejan Glozic <dejan> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||
Severity: | critical | ||||||||||||
Priority: | P1 | ||||||||||||
Version: | 2.0 | ||||||||||||
Target Milestone: | 2.0 F3 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows 2000 | ||||||||||||
Whiteboard: | |||||||||||||
Bug Depends on: | 19248, 19249 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
Kevin McGuire
2002-06-04 16:00:09 EDT
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. |