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

[Carlos Sanchez <carlos.sanchez@xxxxxxxxxxx>]

Carlos Sanchez wrote:
> 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


sorry, I meant slipped. For some reason those sections of the proposal
were outdated, and you were the first one to notice.

I have updated the sections "Build Management", "Build Server" and
"Project Community Provisioning and Maintenance" in the working proposal
http://wiki.eclipse.org/Kepler_Working_Proposal to clarify some aspects
and align with the conversations we had in the newsgroup, in
conferences,... and I'm sending it to EMO to update the official proposal.


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