|
Hi, Benjamin.
I'm interested in this topic, just had a backlog of mail after a long holiday weekend. ;-)
I didn't consider EMF in the original p2 UI work, primarily due to existing platform prereqs and having experience already with building platform UI constructs using the standard JFace layer.
That said, I had problems with the lower level async retrieval/filtering/checkbox implementations and we are looking at data binding to see if it can help. (See bug #233269).
As far as the end user interaction with p2 goes,I've never been driven to look at something like EMF because there is not a lot of exposure of the underlying model to the user. I think it's a more natural fit in tooling where the user is creating/manipulating the model objects directly.
If parts of EMF end up in the core e4 workbench model, it might be natural to move in that direction in the e4 space.
Your experience also interests me when thinking about which parts of the p2 UI code might become API. I've always thought that larger building blocks (the ability to show installed and available views anywhere in an app's UI) are more important than providing lots of API for smaller units of reuse like our label or content providers. Your experience suggests that it might be prudent to avoid introducing much low-level p2 UI API until some of the larger issues surrounding e4, EMF, workbench model, etc. are fleshed out.
I can't really speak for the core part of p2 and don't have the EMF experience to know what it would mean to make the engine "directly available as an EMF API" but I'm interested in that discussion.
susan
![Inactive hide details for Benjamin CABÉ <benjamin.cabe@xxxxxxxxxxxxxxxx>]() Benjamin CABÉ <benjamin.cabe@xxxxxxxxxxxxxxxx>
![]()
| ![]()
| ![]()
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc:
Subject: Re: [p2-dev] p2, authoring, and EMF? |
Is nobody interested in this topic ? :-)
Regards,
Benjamin.
Benjamin CABÉ a écrit :
Hi all,
We've made some further work on the "p2 authoring tools" and developed an early prototype of a metadata repository editor, which is quite similar to what the "Update site editor" proposes.
A requirement document has been initialized on the wiki (http://wiki.eclipse.org/Equinox_p2_Metadata_Repository_Authoring).
We'd like to have some feedback from the p2 community about the choice we made to use an EMF model behind the editor, to ease the GUI development (databinding, EMF content & label providers, undo/redo, ...). This model is very close to the p2 API (see attached class diagram).
At the moment, what we've done is to bind the editor to our metadata repository "EObject", and propose a "content.xml export" action that converts our EMF model to p2 API classes. This is something very trivial, and that works well, *but* we think it would be great to think about having the p2 engine directly available as an EMF API.
Some work has already been done to make EMF Core, Edit, and Edit.UI Foundation 1.1 compatible (see bug #215378) ; and the discussion about having more EMF inside e4 (e.g. an EMF workbench model) came to the conclusion, AFAIK, that EMF is kind of great and can keep a very tiny footprint.
In the p2 context, having an EMF model would allow :
- more trivial XML serialization/unserialization
- listening to model changes
- UI writing simplified (a lot!)
- Databinding
- Undo/Redo
- Treeviewers, labelproviders, etc. much simpler using the EMF.Edit layer
From what we have seen, most of the p2 API (IMetadataRepository, IInstallableUnit, ...) have implementations that are quite straightforward (getters and setters directly bound to their underlying attribute), and the constructors could easily be replaced by the EMF generated factories.
What do you, p2 gurus, think about having more EMF in p2? Is it something that has already been discussed?
Cheers,
Benjamin.
--
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
