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