[news.eclipse.technology.kepler] Thoughts on a Common Project Model

[Philip Dodds <philip.dodds@xxxxxxxxx>]

User-Agent: Unison/1.7.9

We have been doing some thinking on creating an extensible common 
project model.

Why do we need a common project model?

A large part of providing a holistic view of the community resources 
and technologies in play within a project is understanding broader 
information about the project.  The Maven styled pom.xml adds a rich 
set of information that can be used to understand both the structure of 
the project, its dependencies but also additional information that 
would support a developer looking to work in a loosely coupled manager 
with a project.

With collaboration at the heart of Kepler we first need to be able to 
create a common set of meta-data from which we can work - linking out 
to existing Eclipse projects where applicable (ie. Mylyn or the SCM 
projects).   This would benefit each of the toolings - and also we 
would be able to leverage their use within an Eclipse instance to help 
build a common collection of meta-data (an example being when you share 
a project over SCM that would enable the common model to gather 
information about the source repository).

Thoughts on the implementation are as follows:

a) There is a number of sources of project information currently in 
existence within projects,  examples would be PDE files, MANIFEST.MF, 
.settings of the projects and also technologies such as Apache Maven.

b) Creating a single fixed common project model would be difficult as 
different tools not only provide difficult levels of information there 
is also information provided by some tools that are not provided by 
others.

c) We should look to identify the core aspects that we believe a common 
project model could hold - and then provide points where other types of 
meta-data can simply be extended from that.

d) We would need to provide a suite of converters that would allow one 
or more sources to be used to generate a representation of the common 
project model.  This might mean that you could pass a project in 
Eclipse to the conversion and it would identify that meta-data is 
available from say PDE and Maven or Maven and .classpath.   It would 
then allow these converters to build a representation of the common 
model based on the sources.

d) The extensions would be understood by the converters such that a 
simple .project might be able to provide core information (project id) 
and then an additional facet (such as source directories).  While a 
Maven pom.xml would be able to provide core information (projectId), 
source structure facets and also community facets such as mailing lists 
etc.

e) Each converter would register which facets it is capable of both 
creating from its source meta-data and also which ones it is capable of 
storing.

f) A common project editor would allow you to then source this core 
information (including details of the converters) you could then add 
additional facets - these would then be stored in a Kepler project file.

Based on this concept we are thinking that the common model could be 
built as a core XSD with others importing the core and adding to it.  
We'll look to post information on the example schema,  though using a 
schema would allow us to build the model using EMF for use within 
Eclipse.


A couple of questions for people about terms -

Is Common Project Model the right term?

Is using the term Converters - I have been wondering if this is a part 
of being adaptable?  ie.  can you adapt from whatever to this model?  
though the idea of being able to determine what facets can be adapted 
and what facets you can't handle would make this a little more complex?

Also is the term facet good - it does clash with the WTP facet concepts?

As always we are very welcoming of input and thoughts :)

Cheers

P