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

[Thomas Hallgren <thomas@xxxxxxx>]

Hi John,

John Casey wrote:
> 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.
Of course we're interested. We have good reason to be among the initial committers in the 
Kepler proposal :)

The comments we've made so far are intended to help improve the proposal and the project 
plan. We really want to bring things forward and we think the best way to do that is to 
elaborate and integrate already existing Eclipse Technology.

You mentioned "resources available for the project" in your announcement of the project plan 
but as far as I'm aware there was never a discussion around resources. The way we see it, we 
(the Buckminster team ;) ) are working full time in order to provide almost exactly what's 
being described in Kepler as "Build Management". We were somewhat surprised that you didn't 
talk to us before nor had any mention of that in your project plan.

You don't need to speak "for us". We are right here. Always open to discussions.


> ...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. 
>
Obviously, we need to increase the knowledge transfer between Kepler and other Eclipse 
projects. We already have the common assembly and build infrastructure in which other builds 
(PDE, Maven, and others like Ivy) can be plugged in. That's the whole point with Buckminster.


> I don't really understand why you think we're aiming to rewrite 
> technologies already present.
>
You proposed a project plan where you suggest external technology to be brought in, improved 
upon, and then play roles that we feel existing Eclipse Technology projects are capable of 
doing already. If you did that just to start a discussion, you did succeed very well.



> 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.
Buckminster aims to define the assembly and build management part as a common, domain 
agnostic model. We already do parse several different meta-data formats into a generic form. 
You became a committer in the Buckminster project partly so that you could help us integrate 
Maven artifacts and metadata into that model. To be honest, I'm a bit confused about the 
confusion.

Do you feel that Buckminster is inaccurate for this task and that we need something else? If 
so, what is it in Buckminster that you don't like and how can we improve it? We have seen no 
comments from you so far.



> 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.
Can you please elaborate on this? How can we improve the CSPEC so that it is more aligned 
with your objectives with Kepler? We don't want the CSPEC to become one of the domain 
specific models in Kepler. We feel that it should become *part of* that model and we are 
very open to suggestions on how to improve it.

I thought we agreed already in Portland that the CSPEC was a great start when defining the 
build specific part of the common model. What changed?



> 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 propose that we augment the generated common model with information that makes it possible 
to get back to the original artifacts and to use the editors that already exists in order to 
make modifications to the model. At least as a first step. Later on, we can provide 
extension-points so that domain specific model providers can hook into a more integrated 
editor framework.

Kind Regards,
Thomas Hallgren