This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Working with big Ant build files in Netbeans could be much less tedious if there were a drop-down listbox with the target names in the editor toolbar, which would work similar to the dropdown list with methods, fields, etc. in the Java Editor. Maybe this could be joined with the already existing Ant Toolbar or some of its code reused? Without this or a similar feature the only way to find a specific target is to remember its name and do a text search on it. An alternative/additional feature might be to add a "goto" menu item to the target nodes in the explorer.
Definitely targets in the Explorer should let you jump to them as their default action, just like e.g. Java methods. Unfortunately this is not implementable until general XML support in NetBeans is substantially improved. Ditto a toolbar - the basic problem is knowing where in the document a target is. No one is working on the XML API improvements AFAIK. We'll see - definitely if the XML API becomes ready we plan to use it for Ant.
Note: this could be implemented "sloppily" (using text searching) without #20532, at the expense of accuracy in unusually formatted build scripts. Consider <target description="Hi!" name="say.hello"><echo>hi</echo></target> <target name = "say.goodbye"> <echo>hi</echo> </target> <target name="all"> <mycustomtask run="parallel"> <!-- These are just made with MyCustomTask.createTarget: --> <target name="say.hello"/> <target name="say.goodbye"/> </mycustomtask> </target> A simple text search, even a clever regexp, is going to get confused by some cases like the ones above, and might miss actual targets, or misreport non-targets. Whereas a proper XML solution, with location information coming from a strict parser, will not become confused. If the textual style is considered a "good enough" solution, feel free to reopen this request. However I don't know of anyone at Sun who would have time to implement this in the foreseeable future, so contributions would be quite welcome.
Ok, in the meantime I found out how to find the positions of "target" elements in a build.xml -- it's extremely simple using a SAX parser with a custom Handler and the Locator provided by the parser. The essential code is approx. 20 LOC. A "sloppy" approach using text search seems inadequate to me given the minor effort needed to implement a SAX-based solution. I'm not sure why such a solution *has* to be using a (not-yet-useful-for-this) NB XML-API when there is a standard API? Unfortunately I myself have no clue where to start integrating something like this in Netbeans :-( Hints which might give a potential contributor a start?
OK. I was hoping to reuse the (DOM) parse of the build script, but you're right, it is easy enough to do an independent SAX parse and then create the drop-down that way. What would be ideal is to expand the scope of this RFE a bit: 0. Consider not just targets, but all top-level elements (data types and tasks too). 1. Open action on target nodes should jump to them in the editor. This should be the default action. Continue to use F6 to run them. 2. As the cursor moves throughout the document, the node selection should change to be the current top-level element; or the main build script node, if outside any top-level element. Then the editor toolbar would simply be a org.openide.explorer.view.ChoiceView displaying the build script node (i.e. showing its children). Clicking a list element would jump to it; moving around would change the displayed list element. This would make the behavior consistent with that of the Java toolbar. As to where to start integrating, well... doing the SAX parse will be by far the easiest part, the hard part is creating the toolbar, registering it to show for Ant scripts, tracking node selections, etc. Inspiration can probably be taken from the editor & java modules. Having the proper XML tool APIs would vastly simplify all this, and probably it is not worth doing without them. However a much simpler toolbar that does no tracking, etc. would be easier to make in the interim - not easy enough to be doable without knowing the NB APIs pretty well, though, I am afraid. You need to make sure the Ant module supplies a specific content type, not just text/xml, in AntEditorSupport. I'm not sure how you go about ensuring that there is an editor kit for this content type - would need to investigate in CloneableEditorSupport etc. Ideally, CES should fall back to using the text/xml kit when text/xml+ant is specified, but I'm not sure if this is implemented yet. Then the layer needs to have a file Editors/text/xml+ant/Toolbars/Default/org-apache-tools-ant-module-Something.instance [need to also check if editor module understands how to merge toolbars from decreasingly specific content types - I have no idea] where org.apache.tools.ant.module.Something (actual package TBD) would need to implement Presenter.Toolbar. It would then need to find the active editor document somehow - maybe via TopComponent.Registry.activatedNodes and EditorCookie. Then it needs to listen to changes in the document, reparse periodically after a three-second grace delay after last key typed, rebuild the drop-down list with info on element positions. Don't forget some kind of accessibility support for the toolbar - some mnemonic to jump to it, I suppose. All doable, but by no means trivial.
Hm, even though I expected this to be more difficult than from first sight, I underestimated this by far :-( Thanks for the tips - I'll see if I can find the time for some "primitive" solution (maybe a good opportunity to learn NB APIs), otherwise I'd suggest to leave this RFE open for future versions, so the idea doesn't get lost?
*** Issue 27729 has been marked as a duplicate of this issue. ***
As a note for others waiting for this: the ant toolbar module available as contribution on http://ant.netbeans.org/servlets/ProjectDownloadList provides the ability to jump to the targets of the selected build.xml.
Simply cannot do it without support from the editor (issue #33980). As the contrib module demonstrates, it is possible to create a global toolbar. But this is poor UI which would not be acceptable for the product; need to have the toolbar inside the editor area, both to avoid clutter in the global toolbar list, and for consistency with Java source files.
Should be done as a Navigator plug-in for F, not as an editor toolbar.
It's been in trunk builds for a few weeks.