Home » Eclipse Projects » Eclipse Platform » extension point schema binding
| extension point schema binding [message #330022] |
Sun, 13 July 2008 09:05  |
Eclipse User |
|
|
|
Originally posted by: ArminG9.gmx.de
Hi all,
hope this is the right group.
I just want to ask if there is any interest in a extension point schema to
java beans binding for the PDE, similar to JAXB? As I have developed
tooling for this and would of course be happy to commit it, however it
would require still some steps (the remaining 20%) to get it 'straight'
and 'comittable'. Time frame would be about 5 weeks from my side.
Regards,
Armin
|
|
| |
| Re: extension point schema binding [message #330043 is a reply to message #330024] |
Mon, 14 July 2008 02:37  |
| Eclipse User |
|
|
|
Originally posted by: ArminG9.gmx.de
Hi Ed,
first, the benefits of .exsd to java binding and other 'pro-arguments':
Heavily reduced code amount and removal of the implicit string interface
usage
(
eg. iConfigurationElement.getChildren("my-child-tag"); or
iExtensionRegistry.getConfigurationElementsFor("my.long.extension.point.id ");
)
when dealing with extension point information.
From my development experience, it's quite annoying to write the extension
point schema parsing code again once you have a running version already
and then find out it needs ultimately total refactoring to get the next
feature in. And, judging from my RCP coaching experience, I must state
that there is not so many people out there dealing with their own
extension points yet. This would explain there is no voices yet asking for
that. But this may change rapidly especially with the server side eclipse
coming up.
Now, the contra-EMF arguments ;)
For sure EMF would be able to generate the binding also, but what I see
there is that:
- it will/may require from the user (the extension point creator)
understanding of both EMF and extension points, which will reduce the
numbers of users
- it will be more client code, as we first have to get the extension
point's DOM element (I think we cannot just dump the whole plugin.xml into
EMF) to get the bound classes.
- there is some way to go to get the convenience methods into the
generated classes, like resource loading, createExecutableExtension method
and listener delegation (IRegistryChangeListener -> BeanListener)
- it will add the emf plugins to every RCP distribution wanting to use the
bound classes. This especially gets to be a problem in the case of the
platform extension points, as it will put the emf runtime plugins to be
part of the eclipse core. My implementation's generated code also depends
on runtime base classes, but ... it is only two base classes, which depend
only on ...core.runtime.* . They could be added to the core.runtime maybe,
so there would be no additional plugins to add to an RCP distribution.
The tooling I have currently would have the following features:
- works with linked .exsds
- a little listener support on the generated beans
- and other little stuff like direct resource loading etc.
- a magic button in the context menu to regenerate the code from the schema
My current implementation uses velocity to generate the bean classes. I
can switch that to JET if it is a problem with
yet-another-third-party-library.
I've written a lot now, sorry for stealing your time and brains. All I
wanted to ask for is if there is some interest in it in the platform team,
and if, if somebody would be accepting to have a look at it and give
advice on how to get it 'in' if platform team approves. As it will have
implications on platform code content, because of the linked schema
concept. My coding generates linked classes when a linked schema is found,
which ultimately means that every platform plugin that provides an
extension point _should_ provide the generated binding code also.
Otherwise the generated code of a schema linking to a platform plugin's
exsd will not compile because of 'Cannot resolve symbol'.
So, any feedback is appreciated :)
Thanks,
Armin
|
|
|
| Re: extension point schema binding [message #330068 is a reply to message #330043] |
Mon, 14 July 2008 06:55 |
| Eclipse User |
|
|
|
Armin,
Comments below.
Armin Groll wrote:
> Hi Ed,
>
> first, the benefits of .exsd to java binding and other
> 'pro-arguments': Heavily reduced code amount and removal of the
> implicit string interface usage (
> eg. iConfigurationElement.getChildren("my-child-tag"); or
> iExtensionRegistry.getConfigurationElementsFor("my.long.extension.point.id ");
> ) when dealing with extension point information.
Yes, the same benefits as avoiding the use of DOM.
> From my development experience, it's quite annoying to write the
> extension point schema parsing code again once you have a running
> version already and then find out it needs ultimately total
> refactoring to get the next feature in.
Writing parsers is never much fun when you could be doing better things.
> And, judging from my RCP coaching experience, I must state that
> there is not so many people out there dealing with their own extension
> points yet. This would explain there is no voices yet asking for that.
> But this may change rapidly especially with the server side eclipse
> coming up.
It's usually not that significant a task...
> Now, the contra-EMF arguments ;)
>
> For sure EMF would be able to generate the binding also, but what I
> see there is that:
> - it will/may require from the user (the extension point creator)
> understanding of both EMF and extension points, which will reduce the
> numbers of users
EMF generates "beans" much like JAXB does. There's always something to
learn even if it's IConfigurationElement or whatever technology anyone
provides to hide it. EMF is also likely to be useful in other parts of
their application so learning it once has value many times.
> - it will be more client code, as we first have to get the extension
> point's DOM element (I think we cannot just dump the whole plugin.xml
> into EMF) to get the bound classes.
EMF can parse directly from DOM so I imagine making it parse from an
IConfigurationElement wouldn't be all that hard.
> - there is some way to go to get the convenience methods into the
> generated classes, like resource loading, createExecutableExtension
> method and listener delegation (IRegistryChangeListener -> BeanListener)
Definitely it would take some work that I assume you've already done.
> - it will add the emf plugins to every RCP distribution wanting to use
> the bound classes.
Whatever is added will add something to every RCP distribution, but
clear whatever is added is optional, and many RCP distributions already
use EMF and hence nothing is added in that case. The platform folks are
looking to use EMF for e4 to help model the workbench and Tom Schindl
has already investigates using EMF for extension point processing, so
for 4.0, it might already be present anyway.
> This especially gets to be a problem in the case of the platform
> extension points, as it will put the emf runtime plugins to be part of
> the eclipse core. My implementation's generated code also depends on
> runtime base classes, but ... it is only two base classes, which
> depend only on ...core.runtime.* .
Often there is a trade-off between what's in the runtime and what's in
the actual generated code. Factoring common things into the runtime
might make the runtime look bigger, but in the end, when lots of
applications are using it, it makes the footprint smaller. EMF actually
works without the eclipse runtime as well as with it, not that that's
relevant in this discussion.
> They could be added to the core.runtime maybe, so there would be no
> additional plugins to add to an RCP distribution.
Anything could be added to the core runtime.
> The tooling I have currently would have the following features:
> - works with linked .exsds
> - a little listener support on the generated beans
> - and other little stuff like direct resource loading etc.
> - a magic button in the context menu to regenerate the code from the
> schema
It sounds pretty interesting, but also sounds pretty much like what EMF
would produce though a lot less general....
>
> My current implementation uses velocity to generate the bean classes.
> I can switch that to JET if it is a problem with
> yet-another-third-party-library.
There's also Xpand.
>
> I've written a lot now, sorry for stealing your time and brains.
Not at all.
> All I wanted to ask for is if there is some interest in it in the
> platform team, and if, if somebody would be accepting to have a look
> at it and give advice on how to get it 'in' if platform team approves.
It sounds like potentially something for the PDE, but the platform in
general is pretty averse to adding things that increase the initial
install or runtime footprint. But your question is addressed at them so
it's up to them to respond.
> As it will have implications on platform code content, because of the
> linked schema concept. My coding generates linked classes when a
> linked schema is found, which ultimately means that every platform
> plugin that provides an extension point _should_ provide the generated
> binding code also. Otherwise the generated code of a schema linking to
> a platform plugin's exsd will not compile because of 'Cannot resolve
> symbol'.
Yes, as in EMF, you'd need to generate code for all the "base" schemas
if you want code for the derived schema.
>
> So, any feedback is appreciated :)
It sounds pretty interesting and obviously I'm too biased to give an
unbiased opinion...
>
> Thanks,
>
> Armin
>
>
|
|
|
| Re: extension point schema binding [message #330173 is a reply to message #330068] |
Fri, 18 July 2008 01:56 |
| Eclipse User |
|
|
|
Originally posted by: ArminG9.gmx.de
Hi Ed,
yes, you do sound a little biased ;) But who wouldn't if he'd have your
position and history. But the strange thing is that there seems to be
either nobody listening from PDE or platform, or it is not of any interest
to them. I can imagine there is a reason against the whole binding exsd
thing, namely that if parsing information from extension points is too
easy, people may start conveying much more information with the
plugin.xml, which will have it's effect on start up time.
So, if none of the platform or pde people will loose a burp here, I assume
it is of no interest. Maybe I'll put my code to sourceforge then someday
if I get the passion to do so.
- thx for your feedback nevertheless
Best Regards,
Armin
|
|
|
| Re: extension point schema binding [message #330181 is a reply to message #330173] |
Fri, 18 July 2008 08:54 |
| Eclipse User |
|
|
|
Armin,
Comments below.
Armin Groll wrote:
> Hi Ed,
>
> yes, you do sound a little biased ;) But who wouldn't if he'd have
> your position and history.
Yes, of course I'm biased. :-P
> But the strange thing is that there seems to be either nobody
> listening from PDE or platform, or it is not of any interest to them.
> I can imagine there is a reason against the whole binding exsd thing,
> namely that if parsing information from extension points is too easy,
> people may start conveying much more information with the plugin.xml,
> which will have it's effect on start up time.
I doubt anyone is trying to ensure it doesn't get too easy.
> So, if none of the platform or pde people will loose a burp here, I
> assume it is of no interest. Maybe I'll put my code to sourceforge
> then someday if I get the passion to do so.
It's hard to get people to take an interest in stuff that's outside
their immediate current focal point. It might be an interesting topic to
bring up in the context of the e4 discussions.
>
> - thx for your feedback nevertheless
>
> Best Regards,
>
> Armin
>
|
|
|
Goto Forum:
Current Time: Fri May 23 00:14:23 EDT 2025
Powered by FUDForum. Page generated in 0.03195 seconds |
Home