Re: [p2-dev] p2, authoring, and EMF?

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

On the editor front, I will echo Susan and others opinions. If it makes things easier to develop, maintain, etc. why not.
However here are a few things that have been learnt in the past wrt tooling an ever changing runtime:
- The editor, models, have to support for backward compatibility (PDE will support current release -2)
- For a non trivial amount of time, the runtime model can change relatively frequently (which may be a point to use some generative technologies)
- Having a runtime model and a "tooling" model that are very close to each others often cause problems

So my main concern revolve around those lessons learnt and primarily model discrepancies. That said I would hope that if we were to choose that route, then it may be possible to feed the EMF generator with the p2 interfaces (or a decorated version thereof) and let the magic happen to generate boiler plate code.

By curiosity, how much gain in time, code written, etc. do you think this will save?

As for using EMF at runtime, I had considered it a while back, but since our IUs are read-only and we are only running over those, EMF did not seem to be a good fit.

PaScaL

Benjamin CABÉ ---29/08/2008 02:11:38 PM---Hi all,

From:	Benjamin CABÉ <benjamin.cabe@xxxxxxxxxxxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	29/08/2008 02:11 PM
Subject:	[p2-dev] p2, authoring, and EMF?

---

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.
--

Benjamin Cabé Expert Eclipse benjamin.cabe@xxxxxxxxxxxxxxxx http://blog.benjamin-cabe.com Tel : +33(0)5 61 00 06 41 Fax : +33(0)5 61 00 51 46

Nouvelle adresse Anyware Technologies Lake Park ZAC de l'Hers - Allée du Lac BP 87216 31672 Labège Cedex France www.anyware-tech.com

[attachment "p2emf.jpg" deleted by Pascal Rapicault/Ottawa/IBM] _______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev