[news.eclipse.technology.kepler] Some comments on the Kepler proposal

[Thomas Hallgren <thomas@xxxxxxx>]

Hi John,

I have some comments/questions on the Kepler proposal 
(http://www.eclipse.org/proposals/kepler). Proposal excerpts are indented with a '>'. I hope 
this format is OK.


=== Community Project Model ===

> The community project model will implement the following requirements:
>
> MUST  provide an API enabling third-party tools to provide project
> information that can be consumed by other integrators via one or more
> Kepler framework.
>
Since this is a requirement that is met by Eclipse when conforming to “the Eclipse way”; 
using extension points etc. this requirement is somewhat superfluous. Suggest instead that 
it should say that Kepler should define a set of extension points for 3d party integration.

> MUST  provide a means of building an in-memory representation of a
> Kepler project, allowing direct-API creation of a project model.
>
This sounds like it would be covered if Kepler uses EMF but that is an implementation 
detail. Why have this is a requirement? There are many implementation issues that are not 
covered.

> MUST include a specification of the project's build tool of choice
>
How does this specification relate to the previous requirement regarding an API that enable 
third party tools? Do you consider the 'build tool of choice' to be the same thing as a 
'third-party tool' in that requirement?

> MUST  provide an API for bidirectional synchronization of project
> model in memory with project-metadata files
>
I think we agreed to strike this requirement during our Project Model phone conference and 
instead let Kepler have a read-only common model that acts as a view of other domain 
specific models and then add mechanisms to extend the domain specific models where needed 
(much like Buckminster does it today).

In Buckminster we settled for an approach where we say that:

1. The common (generated) model is just a VIEW of the original model. You never modify this 
view. You always modify the original model using the tools especially made for that (the 
Eclipse plugin-manifest editor for instance).
2. Since the common model is much more elaborate, the view can be extended. The extension 
can of course be edited using our tools since no domain specific editor exist.
3. The final model is always a merge of the view and its extension.

By doing this, we get rid of some concerns:

1. We never maintain a secondary metadata file unless we need to extend the model beyond the 
capabilities of the domain specific models.
2. An "you attempt to take over the world" discussion is easy to handle.
3. Existing domain models with editors etc. are reused (people feel right at home and we 
don't need to write new editors etc.)
4. A thirdparty tool need not worry about providing API's that would allow us to change 
their model.
5. A thirdparty tool need not worry about providing API's that would enable us to query for 
their capabilities.
6. No ambiguities as to what model is in control
7. Our model is always up-to-date without synchronization procedures and the like.

I think a requirement should be added that Kepler should keep track of the source of the 
information in the Kepler model. This gives the ability to provide editing of all values 
seen through the Kepler model using the domain specific editors. I.e from viewed-value to 
source-value to artifact to editor.




=== Build Management ===

I added 'check' for the items that I think Buckminster supports out-of-the-box. For some 
reason or another, I think it is a good fit :-)

> MUST integrate with project-builder API
>
check

> MUST integrate with Problems and Errors views
>
check

> MUST provide bidirectional synchronization of project changes to and
> from the build metadata
>
check

> MUST import Eclipse project from build metadata
>
The meaning of this is a bit unclear to me. Why would we import a project from metadata? Do 
you mean materialize from some location based on information in metadata (i.e. resolve 
dependencies) or do are you thinking of some repository that built artifacts can be imported 
from during a build?

> MUST export Eclipse project to build metadata
>
Same thing here. I'm uncertain of the term 'build metadata' in the context of import/export

> SHOULD provide catalog-style support for augmenting the build process with
> new steps
>
Who maintains this catalog of build-steps? Do you see a large catalog spanning several 
different languages (Java, C, PHP, etc.) and different aspects (compile, package, deploy, test)?

The proposal should perhaps say that Kepler should provide an extension point where catalog 
support for build steps can be plugged in. Build steps are probably specific to various 
technology domains and I don’t think Kepler should take on the responsibility of putting 
them all in a catalog. Also, since Kepler provides a read only view, editing of artifacts 
(i.e. adding/modifying build steps) is done in the respective domain and with tools provided 
there – thus looking up build-steps while editing is the responsibility of the editor 
developer in that domain. Kepler could provide a view of available build-steps, where the 
various build-mechanisms provide the information.

> SHOULD manage project code and non-code source directories
>
check

> MAY manage token-filtering configuration for non-code source directories
>
token-filtering? In what context. Please elaborate this.

> SHOULD provide support for application debugging within a build
>
Wording is a bit confusing to me. Is this meant to be support for debugging of the 
application, or for debugging of the build process?

> MAY handle accessory builds: that is, builds consisting of tasks
> different from the main build process
>
check

> MAY support for build modifier activation: these alter the build metadata
> or environment under certain circumstances
>
Please elaborate. What is a 'build modifier' and when is it activated and by who?

> SHOULD support editing of build metadata using graphical tools
>
This ties in to the bidirectional mapping. A lot of editors exists in Eclipse already to 
edit PDE build metadata, the same is true for many other project models. I think the scope 
of this project should be to complement these editors where needed. We must of course be 
able to view the model graphically. Editing is much, much harder.

> MUST support editing of build tool configuration
>
>   SHOULD manage build tool configuration per-project, per-workspace,
>   or globally
>
I think this is one of the areas where we need to carefully apply some separation of concern 
between the build manager as such and the tools that it in turn makes use of.

Example 1:
The build manager performs an action 'eclipse.build'. The actor (the tool for this 
particular action) in this case is the Eclipse JDT compiler. It is configurable on a 
per-project and per-workspace basis with editors and the whole shebang.

Example 2:
The build manager performs an action 'make.binary'. The actor in this case is the gnumake 
executable and the eclipse preference scheme (project, workspace, globally) doesn't apply. 
Perhaps the configuration is a property file or actual environment-settings in the makefile 
itself. Editor support? Emacs, Vi :-)

> MUST support for user interactivity in the build process: support builds
> that prompt for input
>
check

> MAY provide linking of Eclipse projects based on project references
> embedded in build metadata
>
Please elaborate this one. Why would I want to link an Eclipse project and to what (I'm 
probably just confused by the terminology)?

Kind Regards,
Thomas Hallgren