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

[Carlos Sanchez <carlos.sanchez@xxxxxxxxxxx>]

Thomas Hallgren wrote:
> 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.

Yes, we know that and we will explore that integration/combination in
the next milestones, but we need now a place to put our code and ideas

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

They are suggested as "possible" although it's not going to be as
extensive as with Maven of course. It could be license, copyright
info,... we haven't went down too much on other sources than Maven yet,
but what we mean is that if you use any other build tool you could still
take advantage (maybe you have a manifest entry for the contact mailing
list, or the developers that participate in the project)


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

mmm, yeah, that seems to have slept, my idea is to maybe store the
location of the build server, as we do with mailing lists, and in build
management should be that we could source from any build system as I
explained before

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

nah, that's not gonna happen, we just have to make sure we can extract
any community info that p2 may add to their IU as we would do with
manifests. My mistake.
>From the update sites we just get the license of the features and the
company IIRC.

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

I think you are describing what we are trying to do ;) create a
complimentary model that holds the community info.
Some of the benefits of starting as separate project (look, I'm not
saying having it always separate) are:

- we have a space to organize ourselves and put our ideas
- we don't hold Buckminster development as Buckminster tries to be
stable and we introduce new ideas
- we don't change the cspec as we go through this starting process



> 
> Regards,
> Thomas Hallgren