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
You are starting to venture into an area
where Eclipse is not too strong, namely the area of collaborative tools. What
I would like to see here is some solid infrastructure that can provide a
generic shared repository that can be shared between potentially
geographically dispersed Eclipse users working together as a team. This
support should provide the following capabilities for a
start.
1.
The ability to store data in a content neutral form. The content should be
able to have internal structure understandable by the content provider but
this content should be opaque to the repository. Content should be stored,
updated and retrieved in units of content blocks that have meaning to the
content providers.
2.
Plugin interfaces to allow the use of databases or other programs such as the
upcoming Stellation as repository sinks.
3.
Plugin interface to allow different authentication policies to be
implemented.
4.
Plugin interface to allow different authorization policies to be
implemented.
5.
Sufficient indexing to allow easy retrieval of named content
sets.
6.
Plugin interfaces to SCM systems to allow versioning of
content.
Immediate areas where this type of facility could be put to good use
include:
1.
Storage of team-wide or organization-wide Eclipse
preferences.
2.
Storage of launch configurations.
3.
Storage of project metadata.
4.
Storage of run/debug configuration information.
Regards
Jonathan Gossage