[news.eclipse.technology.kepler] Re: Proposed Kepler project plan on wik

[John Casey <jcasey@xxxxxxxxxxx>]

First, let me emphasize that this is only a PROPOSED project plan, not 
anything set in stone. My purpose in putting this on the wiki was to 
generate discussion about the tasks and timing that we might pursue to 
get Kepler started...not to dictate anything to anyone.

In the interest of developing an open community, I think it's quite 
important for us to pursue these sorts of discussions in places like 
this newsgroup rather than on private phone calls or chat rooms. So, 
while this might seem like something I've unilaterally decided and 
handed down, I would like it to be the beginning of the conversation.

I have further comments inlined below.

Thanks,

John

BTW, I believe you have access to edit the Kepler wiki; if you have 
proposals, or things you'd like to add to the project plan, you should 
be able to add them both here and in the wiki...


Henrik Lindberg wrote:
> I assume that the functionality covered in milestone 1 is mostly Buckminster 
> technology - it seems like it, as most, if not all of what is listed already 
> works in Buckminster.
>
> Would be nice if that was mentioned in the plan ;). Would also have liked to 
> have discussed milestone dates - Buckminster is after all on a release train 
> for Europa.

I'm not comfortable speaking for the Buckminster team members as to 
where Buckminster features might be integrated along the project plan, 
since this touches on the topic of resource allocation. The hope was 
that you would be interested in augmenting my proposal.

> I don't understand why we should use Mojo from Codehouse. If you think there 
> is something missing in Buckminster, we are very happy to discuss what 
> anyone thinks should be different. I have not looked at Mojo yet, but if it 
> covers functionality that is needed, I think we should discuss that in 
> public before stating that it should be in a certain milestone. Esp. as 
> there are also IP/Licensing issues involved.

My apologies for leaving this in the proposed project plan that hit the 
wiki. However, my understanding was that Kepler is meant first and 
foremost to provide frameworks by which any of a number of 
implementations can be provided to Eclipse users...so, any framework we 
work on to address headless builds should leave open the possibility to 
accommodate Buckminster headless builds, along with Maven headless 
builds using the pde-maven-plugin from the mojo project at Codehaus. 
(That's assuming we even want to get into the issue of headless builds 
in Kepler; it seems to be a bit of a different take on the "build 
management" features, and not really captured in the proposal at 
all...however, I've included it since there seems to be interest within 
parts of the Eclipse Foundation for providing something of a repository 
for common build infrastructure within Kepler)...Again, this is just a 
proposal, and as such it's up for discussion.

> To me, the plan, as it now stands looks like Kepler is planning a rewrite of 
> technology already in Eclipse projects. Which is not a good move, and 
> something we have already agreed not to do. See meeting notes on the wiki: 
> http://wiki.eclipse.org/index.php/11.08.2006_Conference_Call) where we 
> agreed:

I don't really understand why you think we're aiming to rewrite 
technologies already present. We've had a lot of discussion about this 
from the metadata standpoint, and I thought we all agreed that Kepler 
needed a common project model to enable multiple "native" metadata 
formats (including the native parsers, and including things like the 
plugin.xml, etc.) to contribute project instances that all Kepler 
frameworks could use as a common language. Once we have this, it becomes 
relatively simple to develop "provider" plugins that simply translate 
the native metadata object model into the Kepler object model. I'm 
sorry, but I'm confused as to how this constitutes a rewrite of anything.

> -          Kepler should integrate existing tools rather than recreate them
>
> -          Kepler to focus on defining and building a common project model 
> (where John also said in the meeting that this model should be done "the 
> Buckminster way"  - i.e. being a view of the models in other tool domains 
> rather than being bi-directional).

To be clear, I never fully conceded the point that bi-directional 
information flow of project-model data was impractical/impossible. I 
merely agreed that your approach of using the native metadata parsers, 
etc. was a great approach...I might point out, as it relates to the 
comment above this one, that Buckminster itself translates these native 
metadata models into a Buckminster CSPEC. For Kepler, I think the CSPEC 
itself will prove to be a bit too abstract, however.

I think it's critical to understand that as long as we're requiring 
users to edit information in multiple locations for a single project, 
and keep it straight what information is where, we're going to get 
nowhere with respect to easing the complexity of working with that 
project. Instead, we should try to learn something from the Eclipse 
plugin manifest/plugin.xml editor, and at least provide some sort of 
composite/portal-like editor for project metadata. The more integrated a 
view we can provide over this information for the user, the simpler it 
will be to manage all of that information. If we can make it so the user 
doesn't even really know (or, need to know) where in the different 
metadata files a particular configuration lives, IMO we will be 
providing a much more efficient view of that metadata. It's not enough 
to show the information, divorced from the metadata files...we should 
try to give the user the ability to edit that metadata from the 
consolidated view.

I don't want anyone to think that this necessarily means reinventing the 
various metadata editors...what I'm actually wondering about is 
providing a metadata portal of sorts for that project, where editing a 
particular field means spawning the native editor for the metadata file 
containing that piece of information.

> I think those agreements should be reflected in the project proposal. Now, 
> milestone 1 focuses on building (and in a way that looks like a rewrite that 
> excludes the existing projects).

It was not my intention to exclude anyone. However, I didn't want to 
speak for anyone else, either. IMO, there should be plenty of room for 
Kepler committers to work on the exemplary tooling that they are 
interested in providing.

> I also wonder why Continuum is first on the list of continuous build systems 
> to support. There is a lot of support for Cruise Control among Eclipse 
> projects.  If we want to be successful among the Eclipse projects, shouldn't 
> we support technology that is actually being used rather than try to force 
> something new?

Continuum should probably be taken off of the official project planning. 
It's a project that I intend to pursue for exemplary tooling, because I 
believe it's a worthwhile integration. If someone is interested in 
bringing Cruise Control integration to Kepler, they're of course free to 
do that as well...the frameworks we develop should accommodate both of 
them, and others as well.


begin:vcard
fn:John Casey
n:Casey;John
org:Mergere, Inc.;Product Development
adr:Suite 520;;4676 Admiralty Way;Marina del Rey;CA;32608;United States
email;internet:jcasey@xxxxxxxxxxx
title:Senior Architect
url:http://www.mergere.com
version:2.1
end:vcard