[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ant-dev] External Tool Builders
|
I have only used them when developing plug-ins that contribute Ant tasks.
Since when we want to test the tasks we have to have a JAR contributing
them I used to associated an external tool builder (Ant buildfile) to
rebuild the tasks' JAR on full builds. I'm not sure this usecase is too
relevant since I consider it only a consequence of 2 missing features in
the Ant integration:
1) A better way to develop tasks contributed by plug-ins (having to always
build the JAR is not very nice)
2) A shortcut for running an Ant buildfile (associating the buildfile with
full builds was only a convenient way to workaround this one)
I like your suggestions for reusing existing instances of tools. It makes a
lot of sense not to have to create the same tool configuration for every
project. At first I didn't think the case where "an external tool builder
has a reference to a launch configuration that cannot be resolved" was
acceptable but that is probably up to the user to decide what should be
done. There will probably be cases where it makes a lot of sense to share
the external tool and there are others where it makes no sense. Seems that
the user should have the option to choose.
It does not seem to make sense to add to a project an external tool that is
local to the workspace but it is OK to add an external tool from another
project.
Rodrigo
"Darin Wright"
<Darin_Wright@xxxxxxx> To: platform-ant-dev@xxxxxxxxxxx
Sent by: cc:
platform-ant-dev-admin@ Subject: [platform-ant-dev] External Tool Builders
eclipse.org
11/11/2002 04:11 PM
Please respond to
platform-ant-dev
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
