Community
Participate
Working Groups
Build ID: Ganymede M6 Steps To Reproduce: I'm migrating a large set of plugins to Ganymede and for a few of these I'm getting this error: "Plug-ins declaring extensions or extension points must set the singleton directive to true" So that is nice and all, but these plguins neither declar extensions nor extension points so why am I getting this error ? There must be something missing in that error text OR the error is simply a false error. More information: Example of plugin that gets this has an empty plugin.xml and a manifest.mf that looks like this: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %plugin.name Bundle-SymbolicName: org.jboss.ide.eclipse.jdt.core Bundle-Version: 2.0.0 Bundle-ClassPath: org-jboss-ide-eclipse-jdt-core.jar Bundle-Activator: org.jboss.ide.eclipse.jdt.core.JDTCorePlugin Bundle-Vendor: %plugin.provider Bundle-Localization: plugin Export-Package: org.jboss.ide.eclipse.jdt.core, org.jboss.ide.eclipse.jdt.core.classpath, org.jboss.ide.eclipse.jdt.core.util, org.jboss.ide.eclipse.jdt.core.wizards.generation Require-Bundle: org.eclipse.ui.ide, org.eclipse.ui.views, org.eclipse.jface.text, org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors, org.eclipse.core.resources, org.eclipse.ui, org.jboss.ide.eclipse.core, org.jboss.ide.eclipse.ui, org.eclipse.jdt, org.eclipse.jdt.core, org.eclipse.jdt.ui, org.eclipse.core.runtime Eclipse-AutoStart: true The error occurs on Bundle-Symbolicname.
If the plugins.xml is empty, you don't need it. Removing it will fix this issue. Moving to PDE/UI
Ok - I can verify that deleting plugin.xml removed this warning in all 5 plugins I had this issue. So this should IMO be fixed to not show this error, but insted just a Warning about the plugin.xml file not being needed.
When I talked to Chris about this one, he told me that the "error/warning" is generated by checking the presence of the plugins.xml file. This file should be used only for extensions or extension points. The contents of the file is not analyzed at all. So if you don't have any, it should be removed. Maybe the error should be rephrased to also add that empty plugins.xml should be removed.
See Bug 219513 and Bug 224613
I can have a look and propose a patch tonight. The proposed fix is to display neither error nor warning if the plugin.xml is here but defines no extension/extension point.
patches are always welcomed There should be a quickfix to delete the file.
I think this should be marked as a blocker since it is an obviously wrong error. the plugin.xml does not define anything and as such should not get red-flagged.
This is not a blocker because it does not prevent you from running/developing in Eclipse. Reducing to normal as few people have encountered this bug and because there is a simple workaround, deleting the empty file. There are a lot of bugs PDE is looking at for RC1, so I'm marking this as bugday/helpwanted.
If you're plugin.xml doesn't define anything, than remove it? Who put it there?
who put it there ? Eclipse put it there when it created the project. I'm trying to create a patch for this but is bumping into Ganymede now running out of memory on just having one plugin defined....grrr
Created attachment 99437 [details] proposed pde.ui patch
Created attachment 99438 [details] pde.core patch
Ok here is a suggested patch. While doing it I found 2 additional bugs. 1) Resources key had spelling errors 2) the plugin.xml validator (ExtensionsErrorReporter) was actually putting a warning about missing extension points if singleton=false even though it did have extension points. It was using the plugin model base which is explicitly listed in BundleErrorReporter as not being reliable. So these two validators were actually fighting the same battle but inconsistently. So that is all fixed now by having both of these validators actually look at the *content* of plugin.xml to be correct. Can we get it in now then ? :) Note: I recall that plugin.xml was *required* at some point so if users are trying to have some plugins being backwards compatible having this wrong error break it would be a shame.
Note: the "content" looking is done by early-exit so this should have zero-to-little impact on any performance plus I made sured I got the progress monitor passed so user stopping the validation will work too.
Max, thanks for these patches ! But could you please use the Eclipse default mechanism to create the patches? (Team / Create patch... on files or projects)
These are directly appliable via Team > Apply patch... Are you seeing any issues ? If that does not work for you then if you can give me the direct cvs/svn urls to the plugins then I could try and redo them (I just did it on the source plugins that came with M7)
There are two problems with your patches. 1) You didn't mark them as patches when you attached them so they are not automatically recognized as text/patches, this is easily worked around. 2) The patches don't apply to our workspaces as the paths don't match exactly. It would be easiest for us if you worked against plugins downloaded from cvs. :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse All of the changes (both pde core and pde ui) can be combined into one patch. When attaching the patch to the bug report, select the 'patch' check box. Thanks.
... and you can even use our beloved Mylyn! :)
Created attachment 99636 [details] comibend patch 1) I checked out from cvs and had zero issues applying the patches so not sure why you feel these 2 patches are not possible to apply to cvs 2) Not sure how mylyn could help here ? :) 3) I did #1 and ran create patch on both and content type is set to patch ...so now you should be able to apply it in one sequence instead of two ;) I hope that helps.
Created attachment 99830 [details] Updated Patch Updated the patch 1) Fixed up some comments and copyrights. 2) Refactored the code to remove code style warnings 3) Removed the changes to the NL files, there is no benefit to the user for this change, and we try to avoid making changes to the NL files after M7. I'm still not entirely convinced this should go in, especially for RC1. We are going to have to scan an additional file when validating, just to fix an error that can be easily fixed by deleting the file. I will let Chris make the final call.
Created attachment 99831 [details] mylyn/context/zip
Chris, please review.
Guys, you can't really consider releasing GA of 3.4 with a problem error that is *incorrect* ? What if I want my plugin to be backwards compatible with versions of eclipse/osgi that required plugin.xml to be present ? What if I just commented out an extension while trying to figure out something else ? What about the conflicting empty plugins.xml warning that already is there ? If you are not going to accept the patch then at least downgrade this to a warning and not an error since what you are actually checking (that plugin.xml exists) is *not* an error. A plugin.xml *with* extension content and singleton=false would be an error - but that is not what the current code base is checking for.
Max, this is on our list of things to look at however other items are taking priority at the moment. I hope you can understand.
(In reply to comment #23) > What if I want my plugin to be backwards compatible with versions of > eclipse/osgi that required plugin.xml to be present ? Which version of OSGi requires the plugin.xml to be present and empty? > What if I just commented out an extension while trying to figure out something > else ? Then the message is correct. > What about the conflicting empty plugins.xml warning that already is there ? It's not a conflicting warning, it is telling you simply that your plugin.xml is useless because it's empty and offers you quickfixes to delete it, add an extension or extension point.
Also, I opened bug 231814 to investigate issues regarding plugin conversion and leaving empty plugin.xmls around.
(In reply to comment #23) > Guys, you can't really consider releasing GA of 3.4 with a problem error that > is *incorrect* ? > > What if I want my plugin to be backwards compatible with versions of > eclipse/osgi that required plugin.xml to be present ? How far do you want to go back? Only platforms < 3.0 require a plugin.xml. For 2.x platforms must leave your plugin.xml intact, it cannot simply be empty. You cannot migrate to a bundle manifest in that case. Instead you must leave all the runtime information in the plugin.xml.
(In reply to comment #24) > Max, this is on our list of things to look at however other items are taking > priority at the moment. I hope you can understand. Yes I know. I'm just saying if you won't accept the full patch then downgrade it to a warning.
> > What if I just commented out an extension while trying to figure out something > > else ? > > Then the message is correct. No it is not - since I'm not declaring any extensions in the plugin.xml at that time. > > What about the conflicting empty plugins.xml warning that already is there ? > > It's not a conflicting warning, it is telling you simply that your plugin.xml > is useless because it's empty and offers you quickfixes to delete it, add an > extension or extension point. It gives wrong compile errors which breaks my build and keeps popping up when I try and launch.
moving to 3.5
3.5 ?! We will let two wrong warnings/errors live for a year ?
In 3.5, no plugin.xml is created until an extension or extension point is added. The quick fix for an empty plugin.xml deletes the file. Marking as works for me.
