[news.eclipse.technology.kepler] Re: Kepler and Buckminster

[Thomas Hallgren <thomas@xxxxxxx>]

Carlos Sanchez wrote:
> In Kepler we try to handle the community aspects of a project,
> independently from any other aspects like build information.

Buckminster is interested in the community aspect. We had several 
discussions with Corona in the past with the objective to provide a good 
integration.

The CSpec is not required to contain aspects related to build 
information. It may contain attributes that in different ways categorize 
or affect the dependency graph but it is still a generic model.

> Buckminster obviously has a much larger scope, such as build system
> abstraction, whereas for Kepler build info is out of scope. Again, in
> other case we would have folded Kepler into Maven.
Your proposed architecture 
http://wiki.eclipse.org/Proposed_Kepler_Architecture suggests model 
adapters for Eclipse PDE, JDT, ANT. These are all excellent sources for 
a build or runtime system. What kind of community information are you 
planning to extract from these files?

I'm reading the original proposal at 
http://www.eclipse.org/proposals/kepler/. It mentions "Build Management" 
as one of the key features of Kepler. Another is "Build Server 
Management". I know that this proposal is outdated but is Kepler a 
completely new project today where none of this apply? Judging from the 
proposed architecture that's not the case.

The presentation that you gave at the Equinox Summit
http://wiki.eclipse.org/images/8/8a/EclipseSummit2007.pdf mentions how 
Kepler meta-data can be used to provision equinox and how you have 
adaptors for Eclipse update sites. You talk about Server Side Eclipse. 
It seems to me your scope is somewhat larger then just the community aspect.


> Although we have different objectives we definitely are going to
> collaborate with Buckminster, as we already did by donating the
> Buckminster Maven integration, and we will continue to look to reuse the
> code and contribute to Buckminster again, and create extension points
> where needed for a smooth integration between both.
>
> I don't see any problem having related technologies in two different
> projects, it allows focusing in a narrower objective. There are other
> examples like P2 that are even closer to what Buckminster already does.
P2 is aimed to provision the Eclipse runtime. A provider that will let 
Buckminster consume its model is already in the making. Keep in mind, 
Buckminster is not the provider per se, we aim to bring things together 
under a common umbrella and in a common model. P2 is similar to Maven or 
the current Eclipse Update Manager for us. Yet another model to map. Yet 
another way of obtaining things from a remote source. I.e. there's no 
overlap between Buckminster and P2. Perhaps there's some misconception 
about objectives and provided technology?

My perception is that Buckminster and Kepler has a large overlap and 
that we both would benefit largely by working together on this. Either 
we extend the cspec or we create a separate model that is complementary 
to it. The extension/complement should not contain the elements already 
covered by the cspec (dependency information, version ranges, etc.). It 
should focus on how to incorporate forums, mailing-lists, newsgroups, 
chat-rooms, web sites, bugzillas, project members, and member roles. 
Such an extension could of course be created as a separate project but 
I'm not sure I see the benefits of doing so.

Regards,
Thomas Hallgren