Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » plugin.xmi vs. plugin.xml
plugin.xmi vs. plugin.xml [message #687076] Fri, 27 May 2011 07:20 Go to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6505
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6505
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 Go to previous message
Eclipse UserFriend
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
Previous Topic:An emf uuid question
Next Topic:(no subject)
Goto Forum:
  


Current Time: Sun Sep 22 16:14:14 GMT 2019

Powered by FUDForum. Page generated in 0.01899 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top