Home » Eclipse Projects » Eclipse Platform » PDE Build and MANIFEST.MF vs plugin.xml
| |
| Re: PDE Build and MANIFEST.MF vs plugin.xml [message #283989 is a reply to message #283986] |
Thu, 14 April 2005 21:02   |
Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
Migrating from the old plug-in manifest to the new bundle manifest (plus
simplified plug-in manifest) is fine (the SDK plug-ins are all
migrating to that model). Can you provide the full stack? What action
did you perform to trigger the problem?
If you have a good reason to believe it is a bug in PDE Build, feel free
to open a PR.
Rafael
John Franey wrote:
> Sorry, about the typo: where I wrote <project> tag, I meant <plugin> tag.
>
> John Franey wrote:
>
>> Developers of a plugin I'm trying to build removed attributes from the
>> <project> tag in the plugin.xml file and created a file called
>> MANIFEST.MF. The data that had appeared as <project> attributes (id,
>> version, provider name, class) now appear in the MANEFEST.MF file.
>>
>> The PDE Build 3.1 M6 fails without the id attribute in the plugin.xml
>> file.
>>
>> !STACK 0
>> org.eclipse.osgi.service.pluginconversion.PluginConversionEx ception:
>> Error parsing plugin manifest. Missing attribute "id" in element
>> "plugin".
>> at
>> org.eclipse.core.runtime.adaptor.PluginConverterImpl.fillPlu ginInfo(PluginConverterImpl.java:94)
>>
>>
>>
>> Should I ask the developers to restore the plugin.xml? or will
>> headless PDE Build get a patch?
>>
>> Thanks,
>> John
|
|
|
| Re: PDE Build and MANIFEST.MF vs plugin.xml [message #284023 is a reply to message #283989] |
Fri, 15 April 2005 14:24 |
 John J. Franey
Messages: 55
Registered: July 2009 |
Member |
|
|
Rafael,
I'd like to learn more about 'old plug-manifest' and 'new bundle
manifest'. I searched in the eclipse web site and the eclipse 3.1 M6
context help for the PDE. I did not find anything helpful. Do you have
a reference (or link) to these topics?
I'm sorry if my posting sounded like a bug report. I have not concluded
that I had hit a bug. The exception segment shows that 3.1 M6 is unable
to parse a plugin.xml file that does not have the 'id' attribute in the
'plugin' tag. Because incorrect input can be sometimes cause an
exception, and because 3.1M6 is subject to faults (not being a final
release), it is not clear to me that the exception indicates incorrect
input or a bug. My question should've been more carefully phrased.
So here is the question again, in a different form: Is a plugin tag
without plugin id (and other) attributes combined with a MANIFEST.MF
file containing a plugin id (and other attributes) valid input for the
PDE Build?
I don't know what this mail list is for if questions of this nature
cannot be posed and answered. However, if this is the wrong forum for
this question, could you please refer me to another forum if it exists?
Thanks,
John
Rafael Chaves wrote:
> Migrating from the old plug-in manifest to the new bundle manifest (plus
> simplified plug-in manifest) is fine (the SDK plug-ins are all
> migrating to that model). Can you provide the full stack? What action
> did you perform to trigger the problem?
>
> If you have a good reason to believe it is a bug in PDE Build, feel free
> to open a PR.
>
> Rafael
>
> John Franey wrote:
>
>> Sorry, about the typo: where I wrote <project> tag, I meant <plugin> tag.
>>
>> John Franey wrote:
>>
>>> Developers of a plugin I'm trying to build removed attributes from
>>> the <project> tag in the plugin.xml file and created a file called
>>> MANIFEST.MF. The data that had appeared as <project> attributes (id,
>>> version, provider name, class) now appear in the MANEFEST.MF file.
>>>
>>> The PDE Build 3.1 M6 fails without the id attribute in the plugin.xml
>>> file.
>>>
>>> !STACK 0
>>> org.eclipse.osgi.service.pluginconversion.PluginConversionEx ception:
>>> Error parsing plugin manifest. Missing attribute "id" in element
>>> "plugin".
>>> at
>>> org.eclipse.core.runtime.adaptor.PluginConverterImpl.fillPlu ginInfo(PluginConverterImpl.java:94)
>>>
>>>
>>>
>>> Should I ask the developers to restore the plugin.xml? or will
>>> headless PDE Build get a patch?
>>>
>>> Thanks,
>>> John
|
|
|
| Re: PDE Build and MANIFEST.MF vs plugin.xml [message #284078 is a reply to message #284023] |
Mon, 18 April 2005 01:13 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.no.ufsc.spam.br
I believe there will be doc on this before 3.1 is released. In 3.0,
bundle manifests where already used, but transparently, so documentation
was not required. In 3.1, the message is that the new format should
preferentially be adopted (although plug-ins using the old format are
supported). I can't think of any pointers at this moment.
> Is a plugin tag
> without plugin id (and other) attributes combined with a MANIFEST.MF
> file containing a plugin id (and other attributes) valid input for the
> PDE Build?
Yes, this is what I tried to say in my previous post. This is the new
format for 3.0/3.1 plug-ins. Runtime supports it, PDE/Build has to
support it as well.
> I don't know what this mail list is for if questions of this nature
> cannot be posed and answered. However, if this is the wrong forum for
> this question, could you please refer me to another forum if it
> exists?
Posting here is fine. I suggested opening a PR because it seemed what
you were doing was correct. If it is not a bug, the developer closing it
will explain what you are doing wrong.
Rafael
John Franey wrote:
>
> Rafael,
>
> I'd like to learn more about 'old plug-manifest' and 'new bundle
> manifest'. I searched in the eclipse web site and the eclipse 3.1 M6
> context help for the PDE. I did not find anything helpful. Do you have
> a reference (or link) to these topics?
>
> I'm sorry if my posting sounded like a bug report. I have not concluded
> that I had hit a bug. The exception segment shows that 3.1 M6 is unable
> to parse a plugin.xml file that does not have the 'id' attribute in the
> 'plugin' tag. Because incorrect input can be sometimes cause an
> exception, and because 3.1M6 is subject to faults (not being a final
> release), it is not clear to me that the exception indicates incorrect
> input or a bug. My question should've been more carefully phrased.
>
> So here is the question again, in a different form: Is a plugin tag
> without plugin id (and other) attributes combined with a MANIFEST.MF
> file containing a plugin id (and other attributes) valid input for the
> PDE Build?
>
> I don't know what this mail list is for if questions of this nature
> cannot be posed and answered. However, if this is the wrong forum for
> this question, could you please refer me to another forum if it exists?
>
> Thanks,
> John
>
> Rafael Chaves wrote:
>
>> Migrating from the old plug-in manifest to the new bundle manifest
>> (plus simplified plug-in manifest) is fine (the SDK plug-ins are all
>> migrating to that model). Can you provide the full stack? What action
>> did you perform to trigger the problem?
>>
>> If you have a good reason to believe it is a bug in PDE Build, feel
>> free to open a PR.
>>
>> Rafael
>>
>> John Franey wrote:
>>
>>> Sorry, about the typo: where I wrote <project> tag, I meant <plugin>
>>> tag.
>>>
>>> John Franey wrote:
>>>
>>>> Developers of a plugin I'm trying to build removed attributes from
>>>> the <project> tag in the plugin.xml file and created a file called
>>>> MANIFEST.MF. The data that had appeared as <project> attributes
>>>> (id, version, provider name, class) now appear in the MANEFEST.MF file.
>>>>
>>>> The PDE Build 3.1 M6 fails without the id attribute in the
>>>> plugin.xml file.
>>>>
>>>> !STACK 0
>>>> org.eclipse.osgi.service.pluginconversion.PluginConversionEx ception:
>>>> Error parsing plugin manifest. Missing attribute "id" in element
>>>> "plugin".
>>>> at
>>>> org.eclipse.core.runtime.adaptor.PluginConverterImpl.fillPlu ginInfo(PluginConverterImpl.java:94)
>>>>
>>>>
>>>>
>>>> Should I ask the developers to restore the plugin.xml? or will
>>>> headless PDE Build get a patch?
>>>>
>>>> Thanks,
>>>> John
|
|
|
| Re: PDE Build and MANIFEST.MF vs plugin.xml [message #284628 is a reply to message #283985] |
Wed, 27 April 2005 21:30 |
| Eclipse User |
|
|
|
Originally posted by: john.eclipsefaq.org
I don't know if you've already found your answer, but I believe your
problem is that you're missing this instruction from the beginning of
your plugin.xml file:
<?eclipse version="3.0"?>
If this instruction is missing, Eclipse believes that you are an "old"
plugin (version 2.1 or earlier), and it tries to build a MANIFEST.MF
file for you. Of course, a plugin id was required prior to Eclipse 3.0,
hence your failure.
If this is the case, the best way to migrate your plugin is to right
click on plugin.xml, and select PDE Tools > Migrate to 3.0. Then, on
the "Overview" pane of the plugin.xml editor, click "create an OSGi
bundle manifest". This will take care of properly converting plugin.xml
and creating a correct MANIFEST.MF.
--
John Franey wrote:
> Developers of a plugin I'm trying to build removed attributes from the
> <project> tag in the plugin.xml file and created a file called
> MANIFEST.MF. The data that had appeared as <project> attributes (id,
> version, provider name, class) now appear in the MANEFEST.MF file.
>
> The PDE Build 3.1 M6 fails without the id attribute in the plugin.xml file.
>
> !STACK 0
> org.eclipse.osgi.service.pluginconversion.PluginConversionEx ception:
> Error parsing plugin manifest. Missing attribute "id" in element "plugin".
> at
> org.eclipse.core.runtime.adaptor.PluginConverterImpl.fillPlu ginInfo(PluginConverterImpl.java:94)
>
>
>
> Should I ask the developers to restore the plugin.xml? or will headless
> PDE Build get a patch?
>
> Thanks,
> John
|
|
|
| Re: PDE Build and MANIFEST.MF vs plugin.xml [message #285000 is a reply to message #284628] |
Thu, 05 May 2005 21:47 |
Paul E. Keyser
Messages: 878
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030306060302060705050205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Say -- we have a similar problem: maybe you could help us too? Please? :)
We have a collection of plugins, originally written under 1.0/2.1, and then migrated to 3.0, using
the "PDE Migration" tool (and loads of hand-coding, too, of course). All but two of our forty-plus
plugins now use the 3.0 system. However, two of our plugins, for reasons no-one can explain, have:
(a) the deprecated AbstractUIPlugin constructor parameterised with IPluginDescriptor -- I have
successfully changed this to the new 3.0-system for all forty-plus of our other plugins, but if I
change it in these two plugins -- like this: (i) delete parameter in the AbstractUIPlugin subclass,
re-organize imports, (ii) change the plugin.xml tag from <import plugin="org.eclipse.core.runtime"/>
to <import plugin="org.eclipse.core.runtime"/>), and (iii) an EXTRA step (apparently the PDE editor
ignores the plugin.xml tag) change "Require-Bundle: org.eclipse.core.runtime.compatibility" to
"Require-Bundle: org.eclipse.core.runtime" -- then these two plugins refuse to load at all, spitting
the callstack in the attached TXT file, where com.foo.bar.stuff is our plugin that Eclipse attempted
to load;
(b) a MANIFEST.MF file which insists upon using the "Bundle-Activator:
org.eclipse.core.internal.compatibility.PluginActivator" and "Require-Bundle:
org.eclipse.core.runtime.compatibility".
Both those plugins have the tag <?eclipse version="3.0"?> in their plugin.xml, and both were
migrated to 3.0 using the "PDE Migration" tool. In at least one of them, the coder responsible (not
me) says that he needs the MANIFEST.MF file in order to get his classes to load correctly. What we
would like to be able to do is to:
(1) find out how this MANIFEST.MF file is generated (the responsible coder cannot recall how he did
it, four months ago);
(2) find out how to make MANIFEST.MF file specify "load the plugins according to the new 3.0 system".
Can you help?
thanks,
Paul
John Arthorne wrote:
> I don't know if you've already found your answer, but I believe your
> problem is that you're missing this instruction from the beginning of
> your plugin.xml file:
>
> <?eclipse version="3.0"?>
>
> If this instruction is missing, Eclipse believes that you are an "old"
> plugin (version 2.1 or earlier), and it tries to build a MANIFEST.MF
> file for you. Of course, a plugin id was required prior to Eclipse 3.0,
> hence your failure.
>
> If this is the case, the best way to migrate your plugin is to right
> click on plugin.xml, and select PDE Tools > Migrate to 3.0. Then, on
> the "Overview" pane of the plugin.xml editor, click "create an OSGi
> bundle manifest". This will take care of properly converting plugin.xml
> and creating a correct MANIFEST.MF.
> --
>
> John Franey wrote:
>
>> Developers of a plugin I'm trying to build removed attributes from the
>> <project> tag in the plugin.xml file and created a file called
>> MANIFEST.MF. The data that had appeared as <project> attributes (id,
>> version, provider name, class) now appear in the MANEFEST.MF file.
>>
>> The PDE Build 3.1 M6 fails without the id attribute in the plugin.xml
>> file.
>>
>> !STACK 0
>> org.eclipse.osgi.service.pluginconversion.PluginConversionEx ception:
>> Error parsing plugin manifest. Missing attribute "id" in element
>> "plugin".
>> at
>> org.eclipse.core.runtime.adaptor.PluginConverterImpl.fillPlu ginInfo(PluginConverterImpl.java:94)
>>
>>
>>
>> Should I ask the developers to restore the plugin.xml? or will
>> headless PDE Build get a patch?
>>
>> Thanks,
>> John
--------------030306060302060705050205
Content-Type: text/plain;
name="MANIFEST.MF_File_Crash.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="MANIFEST.MF_File_Crash.txt"
org.osgi.framework.BundleException: The activator org.eclipse.core.internal.compatibility.PluginActivator for bundle com.foo.bar.stuff is invalid
at org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:158)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleContextImpl.java:933)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.java:421)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.star t(AbstractBundle.java:293)
at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLoca lClass(EclipseClassLoader.java:110)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLo calClass(BundleLoader.java:371)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:402)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass(AbstractClassLoader.java:93)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:307)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:336)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1313)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:131)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:124)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:113)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:196)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java:193)
at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAc tion.java:114)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:247)
at org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:915)
at org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:866)
at org.eclipse.jface.action.ActionContributionItem$7.handleEven t(ActionContributionItem.java:785)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :82)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:2772)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2431)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1377)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:254)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:141)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:96)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:335)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
at org.eclipse.core.launcher.Main.run(Main.java:704)
at org.eclipse.core.launcher.Main.main(Main.java:688)
Caused by: java.lang.ClassNotFoundException: org.eclipse.core.internal.compatibility.PluginActivator
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:404)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass(AbstractClassLoader.java:93)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:307)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:336)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:151)
.... 41 more
Root exception:
java.lang.ClassNotFoundException: org.eclipse.core.internal.compatibility.PluginActivator
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:404)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass(AbstractClassLoader.java:93)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:307)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:336)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.load BundleActivator(AbstractBundle.java:151)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.s tart(BundleContextImpl.java:933)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWor ker(BundleHost.java:421)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.star t(AbstractBundle.java:293)
at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLoca lClass(EclipseClassLoader.java:110)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLo calClass(BundleLoader.java:371)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:402)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass(AbstractClassLoader.java:93)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:307)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:336)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1313)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:131)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:124)
at org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:113)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:196)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:69)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java:193)
at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAc tion.java:114)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:247)
at org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:915)
at org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:866)
at org.eclipse.jface.action.ActionContributionItem$7.handleEven t(ActionContributionItem.java:785)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :82)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:2772)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2431)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1377)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:254)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:141)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:96)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:335)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
at org.eclipse.core.launcher.Main.run(Main.java:704)
at org.eclipse.core.launcher.Main.main(Main.java:688)
--------------030306060302060705050205--
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 03:22:18 GMT 2024
Powered by FUDForum. Page generated in 0.02785 seconds |
] 
Search
Help
Register
Login
Home
