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

["Henrik Lindberg" <glashammer@xxxxxxxxxxx>]

I want to add to Thomas last comment:


>>John wrote
>> 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.
>>
>Thomas Wrote
> 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.

The point I want to make here, is that if Kepler takes on editing of meta 
data from various sources, Kepler becomes a bottleneck and must be in sync 
with all the other components. I think it is far better to entice all other 
projects to integrate into Kepler via API:s. Then it becomes the 
responsability of each project to make sure that they handle their meta data 
editing in a good way. Kepler should show the way, and others should want to 
integrate because it is better and helps users. But Kepler can't just take 
over and do this in isolation. So as a first step, I proposed that we keep 
track of the source of all meta data viewed/handled in Kepler so that it is 
possible to drill down to the apropriate meta data editor. What the next 
step should be is hard to tell; an integrated editor framework seems like a 
good approach, perhaps also work on the modeling side, as the Kepler model 
evolves, it may make sense for different projects to also evolve their meta 
data and models towards a common Kepler model.

Regards
Henrik