Community
Participate
Working Groups
build F3 We need a new variable in external tools to indicate the build kind. Without it, the external tools builders mechanism is incomplete. If it is an easy fix I suggest fixing for F4. From the newsgroup: " hi all, is it possible to configure an external tool to only run when the project is explicitly build, as opposed to the incremental build i get when i compile? it would be cool to be able to generate xdoclet code when i explicitly build the project, but its just plain annoying to have it happend every time i save sincerely morten wilken"
Agree that not being able to do this makes this feature essentially unusable. Should be able to configure the kinds of builds for which an external tool builder runs. This was originally planned, but did not make it into the UI. Adding the UI at this stage is too risky. Adding a variable is less risky, and would be valuable even if we did have such UI support. Should consider for F4. Ryan and Simon, please assess risk of adding this and annotate PR, preferably with code snippets.
Would the option of only running on full builds and never on incremental builds be acceptable instead of the variable solution?
It helps but does not give a lot of flexibility.
I would judge the risk of adding this to be low, because although it involves changes to several classes, they are all minor changes and do not affect the behaviour of the component unless the user makes use of the new variable. I have a potential solution. Following is a summary of the necessary code changes. I have a ZIP of the changes available if needed. Please comment. ExternalTool would have the most changes: ADD private static final String TAG_TOOL_FULL_BUILD_ONLY = "! {tool_show_log}"; //$NON-NLS-1$ ADD public static final String VAR_FULL_BUILD_ONLY = "full_build_only"; // $NON-NLS-1$ ADD private boolean fullBuildOnly = false; ADD get and set methods for fullBuildOnly ADD an argument [boolean fullBuildOnly] to the ExternalTools constructor and modify the constructor call in fromArgumentMap(mar args) ADD to fromArgumentMap(Map ags): String sFullBuildOnly = (String)args.get(TAG_TOOL_FULL_BUILD_ONLY); boolean fullBuildOnly; if (FALSE.equals(sFullBuildOnly)) fullBuildOnly = false; else fullBuildOnly = true; ADD to toArgumentMap(): if (fullBuildOnly) args.put(TAG_TOOL_FULL_BUILD_ONLY, TRUE); else args.put(TAG_TOOL_FULL_BUILD_ONLY, FALSE); OTHER CHANGES: ADD to DefaultRunnerContext.expandVariable(VariableDefinintion, StringBuffer, boolean): if (tool.VAR_FULL_BUILD_ONLY.equals(varDef.name)) { tool.setFullBuildOnly(true); } else { tool.setFullBuildOnly(false); } ExternalToolBuilder.build(...): ExternalTool tool = ExternalTool.fromArgumentMap(args); if (tool != null) { /* ADD THE FOLLOWING IF BLOCK */ if (kind != IncrementalProjectBuilder.FULL_BUILD && tool.getFullBuildOnly()) { return null; } ADD to EditDialog.okPressed(): // Set the tool's fullBuildOnly flag to be true // if ExternalTool.VAR_FULL_BUILD_ONLY was one of // the tool's arguments, or to false otherwise. String temp = argumentsField.getText().trim(); int index = temp.indexOf(ExternalTool.VAR_FULL_BUILD_ONLY); if (index > 0) { tool.setFullBuildOnly(true); } else { tool.setFullBuildOnly(false); }
This looks like adding a variable to the command line changes when the tool is run, rather than simply expanding the variable to indicate the type of build. Although we would like to be able to say when a tool runs, this should be done through new UI, not through a variable. Also, we have 3 kinds of build: full, incremental and autobuild. It may well be that a tool wants to run for full and manual incremental builds but not autobuilds. We should add a variable, e.g. ${BUILD_KIND} which simply expands to "full", "incremental" or "auto" accordingly. This can then be used within an Ant script to trigger the appropriate target. Or, the script could define targets with the same name and the command line could just specify: -target ${BUILD_KIND}.
Adding the ${BUILD_KIND} variable does not address the original problem, unless the user is willing to wrap the javadoc tool in an Ant script. The right solution is to add 3 checkboxes, with defaults as follows: Run on: [X] Full build [ ] Manual incremental build [ ] Auto-build These would only appear on the new/edit external tool builder dialog, not the regular new/edit external tool dialog. This change is too large and too late to consider for 2.0 though. The best we could do is add the ${BUILD_KIND} variable and require external tool builders to use Ant.
Running an empty ant script takes about 2 seconds. If we add the build kind variable and pass it through, and the script checks it and does nothing for the "wrong" kinds of builds, there will still be a 2 second delay for the "wrong" builds. With this in mind, are we gaining enough from adding the build kind variable to make it worthwhile to add it for 2.0? Or should we wait until we can add a full (checkbox) solution after 2.0?
The main problem here is that were are not providing a parameter (Nick's ${BUILD_KIND}) that allows the tool script to determine what kind of build is being done. This functionality was in the original plan but was never implemented. With that variable, it is easy for a user to tailor their builder's behavior to the different kinds of builds. This variable should be added. Introducing a new parameter should be straightforward (the substitution mechanism is already there and working). This would makes the functionality useable. Ryan's observation that it is taking a long time (2 seconds) to invoke a trivial Ant script suggests that there is another problem. It is hard to believe why Ant should be so slow, especially given that Ant is being invoked from the same OS process. However, this is a different problem, and should be entered as a separate bug report.
True, it was mentionned in the original design document the "build type" variable, I must have missed it. Nevertheless, even if we provided this variable, it does not solve the original problem - running an external EXE program (not an Ant script). We can provide the variable, but more importantly, tools need an new attribute on what build type they should run - that away we avoid all the overhead of setting up running the tool. Given we are so close to freezing the code for release 2.0, the best option is to disable external tools in the build process for now until it can be properly done after release 2.0
Users could run an EXE or batch files using Ant scripts as a workaround if only the variable ${BUILD_KIND} was provided. I'm not sure disabling external tools is an option at this point.
About the 2 seconds problem. It does not seem alarming but we do need more investigation on it. Every time an Ant script is run we create a new classloader and put all the necessary JARs in the classpath (ant.jar, xerces.jar, etc...). Given it has to load all the necessary classes again and again it might be where the time is going. We do that for the user to be able to extend the Ant classpath at runtime. But I agree there could be some kind of optimization in this area after 2.0. See bug 20557.
Should add the variable. It should be possible to set up a batch file to test the variable without the overhead of invoking Ant.
Should call it "build type", ${build_type} instead of "build kind" as per the original proposal. To simplify the fix, we can keep the same UI for the interactive external tool dialog and the external tool builder dialog, just change how this variable is bound. When run interactively, it can be bound to "none". When run as a builder, it should be bound to "full", "incremental" or "auto".
Ryan made the requested changes as per Nick's comments above. Checked by Tod and Simon
