[platform-ant-dev] External Tool Builders

["Darin Wright" <Darin_Wright@xxxxxxx>]

We are trying to understand how users actually use the "External Tool Builder" feature, and how they think it should work.

The questions we have are:
(1) Do people use the external tool builder support?
(2) If you use the support, are you happy with how it works?
(3) How would you like to see it work?

Following is a brief description of how the existing support works, and what I do not like about it.

The feature currently allows a user to configure an external tool to run as part of a build. Up until now, the user has been forced to create a "new instance" of a tool to run as part of build (they cannot choose from existing tools). As well, if the user wants the same tool to run for many projects, they would have to create N instances of the tool. The reason for this appears to be an underlying implementation detail. The "builders" for a project, are stored and shared in a repository. To share an external tool as a builder, the tool is serialized/reconstructed as a regular builder with a project's attributes in the repository.

This seems confusing to me. As a user, I would expect to be able to define some tools (ant scripts, and or programs), and later be able to add them to a project, to be run with as part of the build. And, when I make a change in the configuration of a tool, I would expect that change to be picked up in the next build (rather than having to edit the configuration of the tool in each project that I have added it to).

As we move towards launch configurations, there is an opportunity to allow for more flexible external tool builders. We could allow the user to add builders to projects from the existing set of tools defined in the workspace. The catch is that the launch configuration defining the tool would need to be shared in the project that references it (rather than stored in local workspace metadata). (However, launch configruations already support this feature).

Since launch configurations are implemented as handles, it is possible to have one launch configuration and many references to it. However, there would be an issue when an external tool builder has a reference to a launch configuration that cannot be resolved. For example, launch config X is stored in project A, and referenced as a builder in project B. When project B is added to a workspace from the repository, without project A, the launch confguration cannot be found/executed. As well, if launch configuration X were stored locally (i.e. not shraed), then other users would not be able to resolve/run the builder. Thus, launch configurations could provide richer support for external tool builders, but with added complexity. It is not clear to me how we can hide this complexity from the user. 

Darin