Community
Participate
Working Groups
The following which I believe is legal xml: <repository id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"/> (its of the same form as for example <extension-point id="authenticator" name="Authenticator"/>) was changed by PDE during a save to: <repository class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider" id="org.eclipse.team.cvs.core.cvsnature"> </repository> Note the change from "/>" to "</repository>". Until that change by PDE, it thought there was an error in the plugin.xml. I assume its because of that change.
Note that the plugin.xml was *significanlty* changed by PDE, this is just the bit I assume was the problem.
PDE uses Xerces parser to load plug-in model that backs the GUI pages of the manifest editor. This parser works on the document that drives the source page. When you try to switch from the source page to any other GUI page, PDE will reparse the document, update the model and fire 'world changed' event to all the pages to sync up with the source. There was something in the file that tripped Xerces parser - PDE simply reacted to it. When your project has PDE capability (nature), there is also a PDE builder that runs on changes in the manifest file. With PDE perspective, you would have seen the error marker in the file and there would be an error in the task list. Obviously your project has no PDE nature. Users that start with PDE or convert from regular Java to PDE projects will not have this problem.
F3 candidate
I've confirmed that there is no PDE nature on that project. There are a few issues here: - from your comments, I am wondering if there is a bug related to the new xerces parser? - related to 19197, in the case where someone doesn't have a PDE nature, there are still clearly places where PDE knows that there is a problem. Is it possible for PDE to be more clear about where these problems are, and inform me sooner? For example on plugin.xml save? As a last resort, you should not be able to launch if there are problems, or at least be told. >>With PDE perspective, you would have seen the error marker in the file and >>there would be an error in the task list. - I can understand if I got 'punished' by not having a nature, but I shouldn't have to use a PDE specific perspective to find out about errors. In practice I would never use it since I just work on my plugin.xml alongside my java code, and am therefore usually in a java perspective.
<quote> I can understand if I got 'punished' by not having a nature, but I shouldn't have to use a PDE specific perspective to find out about errors. In practice I would never use it since I just work on my plugin.xml alongside my java code, and am therefore usually in a java perspective. </quote> Sorry for making a typo, what I wanted to say is: With PDE NATURE, you would have seen the error marker in the file and there would be an error in the task list. PDE nature will cause PDE builders to run and they would produce error markers irrespective of the perspective you are in.
Ah, I thought maybe it was a typo :)
Handled by notifying users about errors in the launcher and in the launch dialog.
