Home » Eclipse Projects » Equinox » application assembly
| application assembly [message #27777] |
Wed, 02 July 2003 12:27  |
Eclipse User |
|
|
|
At different points along the way we have talked about the need for an
'application assembly' role in deploying eclipse-based applications.
Plugins are for the most part at the component-development role level,
but they do step somewhat into the application assembly level because
the plugin.xml declaratively expresses _implementation_ requirements and
because it declaratively enables the fullfillment of extension-points on
other plugins. This is all fine and good.
Features currently more clearly fall into the 'application-assembly'
area because they express an application as the aggregation of multiple
components.
We have talked about the need for this features.xml layer to be able to
override the <requires> dependencies expressed by the plugin.xml layer.
I also feel we need for the feature.xml, in order to be a true
application assembly tool, to be able to also override more of, if not
all, the declarative aspects of a plugin. In particular the
registration of extensions.
Here is an example use-case:
Let's say I want to build an application that includes the Update
Manager. So my feature includes all the org.eclipse.update.* plugins.
However, the plugin.xml for the org.eclipse.update.ui plugin has the
following:
.... blah ... blah ...
<menu
label="%updateMenu.label"
path="help/helpEnd"
id="org.eclipse.update.ui.updateMenu">
<separator
name="group1">
</separator>
<separator
name="group2">
</separator>
</menu>
.... blah ... blah ...
This forces me to get the update menu in a particular place, under the
"Help" menu.
But what if in my application I don't WANT it under the help menu?
Perhaps I want it somewhere else? Or suppose I don't want it there at
all? What if I only want to use the update.ui plugin for it's libraries
and don't want it to directly supply any of its perspective views or UI
elements?
Right now, my only option is to actually edit the plugin.xml of the
plugin that I want to modify. But that means I've now branched the
contents of the org.eclipse.update.ui plugin and I now have to take care
of and maintain that deviation.
It would be better to be able to override the plugin.xml at the feature
level.
Now, the perfect world would allow me to specify at the feature level
the specific element of the plugin.xml that I want to disable or modify.
Unfortunately, I don't really see a way to do that with <extension>
elements because they are not required to have an ID or name. They
specify a point= attribute, but it is possible to provide multiple
extensions to the same point. If you wanted to override one particular
<extension> there is no way to specify it in the absence of a required
ID or name attribute.
One solution is to change the spec so that either the ID or the Name
attributes of the <extension> element are required. That would allow
one to introduce syntax at the feature level such as
<plugin id="org.eclipse.update.ui" version="2.1.0">
<delete-extension id="<extension_id>"/>
<add-extension
id="whatever"
name="whatever"
point="extension-point-name" >
... define extension ...
</add-extension>
</plugin>
Thus one could at the application-assembly level make discrete
modifications to the declarative behavior of a plugin.
In the absence of required extension ids or names, I think the only
option is to use a syntax that allows one to specify a complete
replacement for the plugin's manifest like so:
<plugin id="org.eclipse.update.ui"
version="2.1.0"
manifest="somefile.xml"/>
Where the path for the manifest file would be relative to the features'
directory.
An alternative would be to, instead of modifying the feature.xml syntax
rather simply add an implicit check inside the feature's directory for a
plugins directory in which any plugin.xml file found there would take
precedent. So for example by including the file:
..../features/myfeature/plugins/org.eclipse.update.ui/plugin .xml
that would automatically override the file
..../plugins/org.eclipse.update.ui/plugin.xml
One more aspect of this is that the overrides should probably be
restricted to prereqs and extensions. It seems to me one wouldn't want
to be overriding certain plugin attributes like vendor, id, version,
etc. And probably not <extension-point> elements either.
Now, one problem I already see with the idea of overriding the
plugin.xml at the feature level is that one can have multiple features
"loaded" (because in truth, currently features are not loaded, only
plugins are loaded). What if two features specified conflicting
overrides for the same plugin?
Does this suggest that we need to establish some order-of-precedence
rules for feature resolution? Or that we need some level above features
to do application assembly? "platform.xml" ?
Thoughts? Ideas?
|
|
|
| Re: application assembly [message #27901 is a reply to message #27777] |
Wed, 02 July 2003 20:51  |
| Eclipse User |
|
|
|
Originally posted by: cagatayk.stop.acm.org
See below:
Mel Martinez wrote:
> At different points along the way we have talked about the need for an
> 'application assembly' role in deploying eclipse-based applications.
> Plugins are for the most part at the component-development role level,
> but they do step somewhat into the application assembly level because
> the plugin.xml declaratively expresses _implementation_ requirements and
> because it declaratively enables the fullfillment of extension-points on
> other plugins. This is all fine and good.
>
> Features currently more clearly fall into the 'application-assembly'
> area because they express an application as the aggregation of multiple
> components.
>
> We have talked about the need for this features.xml layer to be able to
> override the <requires> dependencies expressed by the plugin.xml layer.
>
> I also feel we need for the feature.xml, in order to be a true
> application assembly tool, to be able to also override more of, if not
> all, the declarative aspects of a plugin. In particular the
> registration of extensions.
>
> Here is an example use-case:
>
> Let's say I want to build an application that includes the Update
> Manager. So my feature includes all the org.eclipse.update.* plugins.
> However, the plugin.xml for the org.eclipse.update.ui plugin has the
> following:
>
> ... blah ... blah ...
> <menu
> label="%updateMenu.label"
> path="help/helpEnd"
> id="org.eclipse.update.ui.updateMenu">
> <separator
> name="group1">
> </separator>
> <separator
> name="group2">
> </separator>
> </menu>
> ... blah ... blah ...
>
> This forces me to get the update menu in a particular place, under the
> "Help" menu.
>
> But what if in my application I don't WANT it under the help menu?
> Perhaps I want it somewhere else? Or suppose I don't want it there at
> all? What if I only want to use the update.ui plugin for it's libraries
> and don't want it to directly supply any of its perspective views or UI
> elements?
>
> Right now, my only option is to actually edit the plugin.xml of the
> plugin that I want to modify. But that means I've now branched the
> contents of the org.eclipse.update.ui plugin and I now have to take care
> of and maintain that deviation.
>
Your example is the *exact* same problem I face at the moment.
> It would be better to be able to override the plugin.xml at the feature
> level.
>
> Now, the perfect world would allow me to specify at the feature level
> the specific element of the plugin.xml that I want to disable or modify.
> Unfortunately, I don't really see a way to do that with <extension>
> elements because they are not required to have an ID or name. They
> specify a point= attribute, but it is possible to provide multiple
> extensions to the same point. If you wanted to override one particular
> <extension> there is no way to specify it in the absence of a required
> ID or name attribute.
>
> One solution is to change the spec so that either the ID or the Name
> attributes of the <extension> element are required. That would allow
> one to introduce syntax at the feature level such as
>
> <plugin id="org.eclipse.update.ui" version="2.1.0">
> <delete-extension id="<extension_id>"/>
> <add-extension
> id="whatever"
> name="whatever"
> point="extension-point-name" >
> ... define extension ...
> </add-extension>
> </plugin>
>
> Thus one could at the application-assembly level make discrete
> modifications to the declarative behavior of a plugin.
>
I think it would be acceptable to let features override only uniquely
identified elements in plugin manifest. This allows plugin authors to
have some say on what can be replaced on what can't. Fron the plugin's
perspective, this is much like using optional dependencies to some other
plugin; in each case you won't know (and allowed for the possibility of)
whether the other plugin is going to be there or not. It makes sense
that the plugin should be allowed to control what can be substituted or
removed.
Seperate add-extension and remove-extension elements seem like overkill,
one replace-extension element can be used to refer to another uniquely
identified element in the target plugin; the extension would effectively
be removed if this element were empty.
> In the absence of required extension ids or names, I think the only
> option is to use a syntax that allows one to specify a complete
> replacement for the plugin's manifest like so:
>
> <plugin id="org.eclipse.update.ui"
> version="2.1.0"
> manifest="somefile.xml"/>
>
> Where the path for the manifest file would be relative to the features'
> directory.
>
> An alternative would be to, instead of modifying the feature.xml syntax
> rather simply add an implicit check inside the feature's directory for a
> plugins directory in which any plugin.xml file found there would take
> precedent. So for example by including the file:
>
> .../features/myfeature/plugins/org.eclipse.update.ui/plugin. xml
>
> that would automatically override the file
>
> .../plugins/org.eclipse.update.ui/plugin.xml
>
Wholesale replacement of plugin manifest sounds like it could cause a
lot of duplication and introduce unnecessary complexity to an already
complicated product layout. I guess I can't see the additional benefit
of replacing the whole manifest given the ability to change uniquely
identified elements.
> One more aspect of this is that the overrides should probably be
> restricted to prereqs and extensions. It seems to me one wouldn't want
> to be overriding certain plugin attributes like vendor, id, version,
> etc. And probably not <extension-point> elements either.
>
> Now, one problem I already see with the idea of overriding the
> plugin.xml at the feature level is that one can have multiple features
> "loaded" (because in truth, currently features are not loaded, only
> plugins are loaded). What if two features specified conflicting
> overrides for the same plugin?
>
> Does this suggest that we need to establish some order-of-precedence
> rules for feature resolution? Or that we need some level above features
> to do application assembly? "platform.xml" ?
>
> Thoughts? Ideas?
>
>
>
>
>
|
|
|
| Re: application assembly [message #27941 is a reply to message #27901] |
Thu, 03 July 2003 11:34 |
| Eclipse User |
|
|
|
Cagatay Kavukcuoglu wrote:
> See below:
>
> Mel Martinez wrote:
>
>>
>> Here is an example use-case:
>>
>> Let's say I want to build an application that includes the Update
>> Manager. So my feature includes all the org.eclipse.update.* plugins.
>> However, the plugin.xml for the org.eclipse.update.ui plugin has the
>> following:
>>
>> ... blah ... blah ...
>> <menu
>> label="%updateMenu.label"
>> path="help/helpEnd"
>> id="org.eclipse.update.ui.updateMenu">
>> <separator
>> name="group1">
>> </separator>
>> <separator
>> name="group2">
>> </separator>
>> </menu>
>> ... blah ... blah ...
>>
>> This forces me to get the update menu in a particular place, under the
>> "Help" menu.
>>
>> But what if in my application I don't WANT it under the help menu?
>> Perhaps I want it somewhere else? Or suppose I don't want it there at
>> all? What if I only want to use the update.ui plugin for it's
>> libraries and don't want it to directly supply any of its perspective
>> views or UI elements?
>>
>> Right now, my only option is to actually edit the plugin.xml of the
>> plugin that I want to modify. But that means I've now branched the
>> contents of the org.eclipse.update.ui plugin and I now have to take
>> care of and maintain that deviation.
>>
>
> Your example is the *exact* same problem I face at the moment.
>
>> It would be better to be able to override the plugin.xml at the
>> feature level.
>>
>> Now, the perfect world would allow me to specify at the feature level
>> the specific element of the plugin.xml that I want to disable or
>> modify. Unfortunately, I don't really see a way to do that with
>> <extension> elements because they are not required to have an ID or
>> name. They specify a point= attribute, but it is possible to provide
>> multiple extensions to the same point. If you wanted to override one
>> particular <extension> there is no way to specify it in the absence of
>> a required ID or name attribute.
>>
>> One solution is to change the spec so that either the ID or the Name
>> attributes of the <extension> element are required. That would allow
>> one to introduce syntax at the feature level such as
>>
>> <plugin id="org.eclipse.update.ui" version="2.1.0">
>> <delete-extension id="<extension_id>"/>
>> <add-extension
>> id="whatever"
>> name="whatever"
>> point="extension-point-name" >
>> ... define extension ...
>> </add-extension>
>> </plugin>
>>
>> Thus one could at the application-assembly level make discrete
>> modifications to the declarative behavior of a plugin.
>>
>
> I think it would be acceptable to let features override only uniquely
> identified elements in plugin manifest. This allows plugin authors to
> have some say on what can be replaced on what can't. Fron the plugin's
> perspective, this is much like using optional dependencies to some other
> plugin; in each case you won't know (and allowed for the possibility of)
> whether the other plugin is going to be there or not. It makes sense
> that the plugin should be allowed to control what can be substituted or
> removed.
>
I think that fundamentally that the two elements from plugin.xml that an
application assembler should always be able to override are <requires>
and <extension>. Those two elements are declarations of specific
connections to other plugins and thus really in the province of
application assembly. The other elements, <plugin [attributes]>,
<runtime>, <extension-point> and <fragment> are all declarations that
describe just the plugin itself and thus are not assembly declarations.
> Seperate add-extension and remove-extension elements seem like overkill,
> one replace-extension element can be used to refer to another uniquely
> identified element in the target plugin; the extension would effectively
> be removed if this element were empty.
>
Semantically, you want to be able to add, delete and modify (replace)
extensions. While an empty <replace> implies deletion, I'm not sure
how you use <replace> to imply addition. I.E. one needs to be able to
add new extensions in addition to the default ones provided by the
plugin. <delete> and <add> are sufficient to also imply replacement.
>> In the absence of required extension ids or names, I think the only
>> option is to use a syntax that allows one to specify a complete
>> replacement for the plugin's manifest like so:
>>
>
>
> Wholesale replacement of plugin manifest sounds like it could cause a
> lot of duplication and introduce unnecessary complexity to an already
> complicated product layout. I guess I can't see the additional benefit
> of replacing the whole manifest given the ability to change uniquely
> identified elements.
>
I agree. My preference would be to have a discrete element syntax.
Unfortunately the only way I see to get that to work is to require IDs
or names for <extension>s. Actually, we could still get it to work in
the case where you don't have ids provided by the plugin author by using
something like
<delete-extension id="*"/>
..... add entirely new <extension>s ...
I like this idea because it gets away from having to override with a
separate markup unit and we can use discrete element directives. Since
the feature author has access to the plugin.xml, it is trivial to
copy&paste the elements he needs to preserve in this delete "*" case.
>>
>> Now, one problem I already see with the idea of overriding the
>> plugin.xml at the feature level is that one can have multiple features
>> "loaded" (because in truth, currently features are not loaded, only
>> plugins are loaded). What if two features specified conflicting
>> overrides for the same plugin?
>>
>> Does this suggest that we need to establish some order-of-precedence
>> rules for feature resolution? Or that we need some level above
>> features to do application assembly? "platform.xml" ?
>>
I'm still not sure what to do about this. Does this get handled by
'scoping' of extension-point / extension resolution ? One rule might be
to use preference based on which feature is 'primary' at startup. Maybe
this isn't a big enough issue to worry about?
|
|
|
| Re: application assembly [message #27981 is a reply to message #27941] |
Mon, 07 July 2003 14:03 |
| Eclipse User |
|
|
|
Originally posted by: birsan.nospam.ca.ibm.com
So, if a plugin.xml is to be overridden by a feature, should its version
number change?
My guess is that it should, in which case your scenario can be addressed in
a different manner: in eclipse 3.0 we have been discussing the idea of
shipping updates that only contain deltas. For example, if only plugin.xml
and foo.jar in a plugin have changed, then the feature will contain the
necessary markup to tell the update manager to use files from the old
plugin, except the new plugin.xml and new foo.jar which will be downloaded.
I assume this would work in the scenario that you describe, where one can
package the plugin to only contain the new plugin.xml only. Would this be
good enough for what you're after?
-Dorian
"Mel Martinez" <melm@us.ibm.com> wrote in message
news:be1idi$saf$1@rogue.oti.com...
> Cagatay Kavukcuoglu wrote:
>
> > See below:
> >
> > Mel Martinez wrote:
> >
> >>
> >> Here is an example use-case:
> >>
> >> Let's say I want to build an application that includes the Update
> >> Manager. So my feature includes all the org.eclipse.update.* plugins.
> >> However, the plugin.xml for the org.eclipse.update.ui plugin has the
> >> following:
> >>
> >> ... blah ... blah ...
> >> <menu
> >> label="%updateMenu.label"
> >> path="help/helpEnd"
> >> id="org.eclipse.update.ui.updateMenu">
> >> <separator
> >> name="group1">
> >> </separator>
> >> <separator
> >> name="group2">
> >> </separator>
> >> </menu>
> >> ... blah ... blah ...
> >>
> >> This forces me to get the update menu in a particular place, under the
> >> "Help" menu.
> >>
> >> But what if in my application I don't WANT it under the help menu?
> >> Perhaps I want it somewhere else? Or suppose I don't want it there at
> >> all? What if I only want to use the update.ui plugin for it's
> >> libraries and don't want it to directly supply any of its perspective
> >> views or UI elements?
> >>
> >> Right now, my only option is to actually edit the plugin.xml of the
> >> plugin that I want to modify. But that means I've now branched the
> >> contents of the org.eclipse.update.ui plugin and I now have to take
> >> care of and maintain that deviation.
> >>
> >
> > Your example is the *exact* same problem I face at the moment.
> >
> >> It would be better to be able to override the plugin.xml at the
> >> feature level.
> >>
> >> Now, the perfect world would allow me to specify at the feature level
> >> the specific element of the plugin.xml that I want to disable or
> >> modify. Unfortunately, I don't really see a way to do that with
> >> <extension> elements because they are not required to have an ID or
> >> name. They specify a point= attribute, but it is possible to provide
> >> multiple extensions to the same point. If you wanted to override one
> >> particular <extension> there is no way to specify it in the absence of
> >> a required ID or name attribute.
> >>
> >> One solution is to change the spec so that either the ID or the Name
> >> attributes of the <extension> element are required. That would allow
> >> one to introduce syntax at the feature level such as
> >>
> >> <plugin id="org.eclipse.update.ui" version="2.1.0">
> >> <delete-extension id="<extension_id>"/>
> >> <add-extension
> >> id="whatever"
> >> name="whatever"
> >> point="extension-point-name" >
> >> ... define extension ...
> >> </add-extension>
> >> </plugin>
> >>
> >> Thus one could at the application-assembly level make discrete
> >> modifications to the declarative behavior of a plugin.
> >>
> >
> > I think it would be acceptable to let features override only uniquely
> > identified elements in plugin manifest. This allows plugin authors to
> > have some say on what can be replaced on what can't. Fron the plugin's
> > perspective, this is much like using optional dependencies to some other
> > plugin; in each case you won't know (and allowed for the possibility of)
> > whether the other plugin is going to be there or not. It makes sense
> > that the plugin should be allowed to control what can be substituted or
> > removed.
> >
>
> I think that fundamentally that the two elements from plugin.xml that an
> application assembler should always be able to override are <requires>
> and <extension>. Those two elements are declarations of specific
> connections to other plugins and thus really in the province of
> application assembly. The other elements, <plugin [attributes]>,
> <runtime>, <extension-point> and <fragment> are all declarations that
> describe just the plugin itself and thus are not assembly declarations.
>
> > Seperate add-extension and remove-extension elements seem like overkill,
> > one replace-extension element can be used to refer to another uniquely
> > identified element in the target plugin; the extension would effectively
> > be removed if this element were empty.
> >
>
> Semantically, you want to be able to add, delete and modify (replace)
> extensions. While an empty <replace> implies deletion, I'm not sure
> how you use <replace> to imply addition. I.E. one needs to be able to
> add new extensions in addition to the default ones provided by the
> plugin. <delete> and <add> are sufficient to also imply replacement.
>
> >> In the absence of required extension ids or names, I think the only
> >> option is to use a syntax that allows one to specify a complete
> >> replacement for the plugin's manifest like so:
> >>
> >
> >
> > Wholesale replacement of plugin manifest sounds like it could cause a
> > lot of duplication and introduce unnecessary complexity to an already
> > complicated product layout. I guess I can't see the additional benefit
> > of replacing the whole manifest given the ability to change uniquely
> > identified elements.
> >
>
> I agree. My preference would be to have a discrete element syntax.
> Unfortunately the only way I see to get that to work is to require IDs
> or names for <extension>s. Actually, we could still get it to work in
> the case where you don't have ids provided by the plugin author by using
> something like
> <delete-extension id="*"/>
> .... add entirely new <extension>s ...
>
> I like this idea because it gets away from having to override with a
> separate markup unit and we can use discrete element directives. Since
> the feature author has access to the plugin.xml, it is trivial to
> copy&paste the elements he needs to preserve in this delete "*" case.
>
> >>
> >> Now, one problem I already see with the idea of overriding the
> >> plugin.xml at the feature level is that one can have multiple features
> >> "loaded" (because in truth, currently features are not loaded, only
> >> plugins are loaded). What if two features specified conflicting
> >> overrides for the same plugin?
> >>
> >> Does this suggest that we need to establish some order-of-precedence
> >> rules for feature resolution? Or that we need some level above
> >> features to do application assembly? "platform.xml" ?
> >>
>
> I'm still not sure what to do about this. Does this get handled by
> 'scoping' of extension-point / extension resolution ? One rule might be
> to use preference based on which feature is 'primary' at startup. Maybe
> this isn't a big enough issue to worry about?
>
|
|
|
Goto Forum:
Current Time: Wed May 14 09:56:52 EDT 2025
Powered by FUDForum. Page generated in 0.03811 seconds |
Home