plugin.xmi vs. plugin.xml [message #687076] |
Fri, 27 May 2011 07:20 |
Eclipse User |
|
|
|
Originally posted by:
I've have needed to work with various plugin.xml files a lot lately, and
then it struck me: Why not plugin.xmi, i.e. an instance of a plugin
model? plugin.xml is xml with a schema, right, so it shouldn't be
impossible to automate the translation of plugin.xml's and schemas to a
combination of plugin models and instances (and back). I think the
biggest difficulty is how a plugin.xml combines many kinds of instances
in one file:
- the top-level xml elements are instances of a plugin model (plugin,
extension and extension-point elements), lets call it plugin.ecore
- an extension-point and its associated schema (exsd) introduces a new
model, lets call it <extension-point-name>.ecore
- an extension is an instance of the corresponding <extension-point>.ecore
So, a plugin.xml could be translated to one plugin.xmi and a set of
<extension-point-name>.ecore files.
If this worked we could 1) use EMF to manage plugin.xml and 2) as a
side-effect be able to support merging of plugin.xml when generating EMF
plugin projects (edit & editor).
Just an idea...
Hallvard
|
|
|
Re: plugin.xmi vs. plugin.xml [message #687078 is a reply to message #687076] |
Fri, 27 May 2011 07:45 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Guess what the first e4 prototype had instead of plugin.xml ;-)
BTW what you are requesting is exactly how the e4 contribution mechanism
is working though we still need an plugin.xml - to point e4 to the
correct .e4xmi-File - it is very thin.
And because you can extend the application model there's no need for you
to invent those nasty .exsd-Definitions.
Tom
Am 27.05.11 09:20, schrieb Hallvard Trætteberg:
> I've have needed to work with various plugin.xml files a lot lately, and
> then it struck me: Why not plugin.xmi, i.e. an instance of a plugin
> model? plugin.xml is xml with a schema, right, so it shouldn't be
> impossible to automate the translation of plugin.xml's and schemas to a
> combination of plugin models and instances (and back). I think the
> biggest difficulty is how a plugin.xml combines many kinds of instances
> in one file:
> - the top-level xml elements are instances of a plugin model (plugin,
> extension and extension-point elements), lets call it plugin.ecore
> - an extension-point and its associated schema (exsd) introduces a new
> model, lets call it <extension-point-name>.ecore
> - an extension is an instance of the corresponding <extension-point>.ecore
>
> So, a plugin.xml could be translated to one plugin.xmi and a set of
> <extension-point-name>.ecore files.
>
> If this worked we could 1) use EMF to manage plugin.xml and 2) as a
> side-effect be able to support merging of plugin.xml when generating EMF
> plugin projects (edit & editor).
>
> Just an idea...
>
> Hallvard
|
|
|
Re: plugin.xmi vs. plugin.xml [message #687083 is a reply to message #687078] |
Fri, 27 May 2011 11:35 |
Eclipse User |
|
|
|
Originally posted by:
On 27.05.11 09.45, Tom Schindl wrote:
> Guess what the first e4 prototype had instead of plugin.xml ;-)
>
> BTW what you are requesting is exactly how the e4 contribution mechanism
> is working though we still need an plugin.xml - to point e4 to the
> correct .e4xmi-File - it is very thin.
>
> And because you can extend the application model there's no need for you
> to invent those nasty .exsd-Definitions.
I understand how you can do this, since you can be more revolutionary. I
think for the evolutionary Eclipse 3.x series, you will need an
Ecore-based plugin model to interoperate with plugin.xml, so plugin.xml
and plugin.xmi are essentially the same, but the plugin.xmi will be far
easier to manage for us EMF'ers.
Hallvard
|
|
|
Re: plugin.xmi vs. plugin.xml [message #687288 is a reply to message #687076] |
Fri, 27 May 2011 07:45 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Guess what the first e4 prototype had instead of plugin.xml ;-)
BTW what you are requesting is exactly how the e4 contribution mechanism
is working though we still need an plugin.xml - to point e4 to the
correct .e4xmi-File - it is very thin.
And because you can extend the application model there's no need for you
to invent those nasty .exsd-Definitions.
Tom
Am 27.05.11 09:20, schrieb Hallvard Trætteberg:
> I've have needed to work with various plugin.xml files a lot lately, and
> then it struck me: Why not plugin.xmi, i.e. an instance of a plugin
> model? plugin.xml is xml with a schema, right, so it shouldn't be
> impossible to automate the translation of plugin.xml's and schemas to a
> combination of plugin models and instances (and back). I think the
> biggest difficulty is how a plugin.xml combines many kinds of instances
> in one file:
> - the top-level xml elements are instances of a plugin model (plugin,
> extension and extension-point elements), lets call it plugin.ecore
> - an extension-point and its associated schema (exsd) introduces a new
> model, lets call it <extension-point-name>.ecore
> - an extension is an instance of the corresponding <extension-point>.ecore
>
> So, a plugin.xml could be translated to one plugin.xmi and a set of
> <extension-point-name>.ecore files.
>
> If this worked we could 1) use EMF to manage plugin.xml and 2) as a
> side-effect be able to support merging of plugin.xml when generating EMF
> plugin projects (edit & editor).
>
> Just an idea...
>
> Hallvard
|
|
|
Re: plugin.xmi vs. plugin.xml [message #687296 is a reply to message #687078] |
Fri, 27 May 2011 11:35 |
Eclipse User |
|
|
|
Originally posted by:
On 27.05.11 09.45, Tom Schindl wrote:
> Guess what the first e4 prototype had instead of plugin.xml ;-)
>
> BTW what you are requesting is exactly how the e4 contribution mechanism
> is working though we still need an plugin.xml - to point e4 to the
> correct .e4xmi-File - it is very thin.
>
> And because you can extend the application model there's no need for you
> to invent those nasty .exsd-Definitions.
I understand how you can do this, since you can be more revolutionary. I
think for the evolutionary Eclipse 3.x series, you will need an
Ecore-based plugin model to interoperate with plugin.xml, so plugin.xml
and plugin.xmi are essentially the same, but the plugin.xmi will be far
easier to manage for us EMF'ers.
Hallvard
|
|
|
Powered by
FUDForum. Page generated in 0.05011 seconds