[news.eclipse.technology.alf] Project Model discussion in Kepler

[John Casey <jcasey@xxxxxxxxxxx>]

Hi everyone,

I wanted to invite anyone who might be interested to participate in a 
discussion we've been having in the (proposed) Kepler project newsgroup. 
We're attempting to define a unified project model which can contain all 
relevant information about a project, including:

* description of the project, including URLs to issue tracking, etc.
* description of project dependencies
* configuration of project build process
* other development-process metadata for the project

The goal is to provide a single API where any third-party tool or 
Eclipse plugin could contribute project information or read it from 
other providers. Once we have a common API for querying project 
information, we can write adapters for any/all third-party tools we wish 
to integrate. At that point, we can write our own frameworks and tools 
to use this API and take advantage of existing providers.

Originally, this effort was purely self-serving, in order to allow 
Kepler frameworks to integrate with one another and draw on project 
information from tools that overlapped between feature-sets. However, 
the Corona and Buckminster projects have shown a definite interest in 
collaborating on this, to make it a more generalized API for storing and 
accessing this sort of information. Now, we're thinking it might be good 
to have as many collaboration- and process-oriented frameworks provide 
input, to see how far we can get toward a generalized API for project 
information.

To be clear: We're not interested in *converting* existing project 
metadata files to some new format. We're not interested in replacing the 
.project, .classpath, pom.xml, build.xml, etc. files that are already 
out there. Instead, we'd like to provide adapters to read all of these 
file formats and expose their information as part of the project API we 
hope to create. When a project instance is modified, we'd like to be 
able to write to these disparate metadata files where possible, and 
augment their information with an extension file (similar to 
Buckminster's .cspecex file) where it's not possible.

So, if you're interested in participating in this discussion, pop on 
over to the eclipse.technology.kepler newsgroup, and join in! We'd like 
to hear your ideas, even if you're unable to commit any time for code 
production for Kepler.

Thanks for your time,

John Casey