RE: [platform-ant-dev] External Tool Builders

["Darin Wright" <Darin_Wright@xxxxxxx>]

Although the external tools plug-in could benefit from features you have suggested - it is not really the job of the external tools plug-in to provide such infrastructure. These feature requests should really be filed against the "team" component, that deals with repositories.

The intent of this poll is to find out if and how people use the "External Tools Builders" property of a project.

Darin

"Jonathan Gossage" <jgossage@xxxxxxxx> Sent by: platform-ant-dev-admin@xxxxxxxxxxx 11/12/2002 04:32 AM Please respond to platform-ant-dev

To:        <platform-ant-dev@xxxxxxxxxxx>         cc:                 Subject:        RE: [platform-ant-dev] External Tool Builders

-----Original Message-----
From: platform-ant-dev-admin@xxxxxxxxxxx [mailto:platform-ant-dev-admin@xxxxxxxxxxx]On Behalf Of Darin Wright
Sent: November 11, 2002 4:12 PM
To: platform-ant-dev@xxxxxxxxxxx
Subject: [platform-ant-dev] External Tool Builders


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