[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [p2-dev] p2, authoring, and EMF?

Yeah, Wind River is looking forward to helping build a great authoring tool that we can use for our internal generation of our repos as well! :)

-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Thursday, September 04, 2008 6:57 PM
To: P2 developer discussions
Subject: RE: [p2-dev] p2, authoring, and EMF?

I sure am. I'll take a look when I can get my head above water long enough.
 
Cheers,
Doug


________________________________

	From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Benjamin CABÉ
	Sent: Thursday, September 04, 2008 5:06 AM
	To: P2 developer discussions
	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.
		
		-- 
		
Anyware Technologies <http://www.anyware-tech.com>  	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 

________________________________


		
		
________________________________


		_______________________________________________
		p2-dev mailing list
		p2-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/p2-dev
		  



	-- 
	
Anyware Technologies <http://www.anyware-tech.com>  	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