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.
The property Ant Home for Options | Building | Ant Settings has not a specific editor that open the file browser to be able to select the directory or file where ant is located. Would be friendler, and not so difficult because it's not necessary to develop a new property editor.
[IDE 200311130740] The trouble is that it possibly *is* necessary to develop a new property editor. I initially had it using the normal java.io.File editor. However this turned out to be very, very bad - every time you selected a directory in the chooser (to navigate into) the property editor would send a change back to AntSettings, causing it to attempt to reload the Ant installation from some bogus location, throwing a bunch of exceptions internally that had to be caught one by one, and causing poor performance. So this is blocked by the need to have a way to ask the java.io.File editor to not call setValue unless and until the user actually closes the dialog. Ideally would also permit AntSettings to reject the change (keeping the dialog open) after the user presses OK, if the directory is found to not be an Ant installation - though maybe a quick check can be done for every new directory whether it simply has lib/ant.jar.
Well, we could try something like the (untested) attachment: your Property can return a FileFilter from getValue("valueFilter"). SetValue on the property editor will never be called unless the filter accepts the result. Your accept() implementation will need to figure out if the selected directory represents a valid ant install or not. The problem is that the instant calls to setValue on selection changes are needed by wizards in order to enable/disable the Next/Finish buttons. A real API with a contract for how custom editors behave would solve much of this - as it is, the custom editor code works mainly by caching the old value and restoring it if the user clicks cancel. EnhancedCustomPropertyEditor would let you do this...and is deprecated (well, we could use something with a little more contract than that offers anyway).
Created attachment 12200 [details] Patch to file editor to allow filtering of values that will trigger a call to setValue. I don't know if it will work.
If it's possible for the Working directory of External Execution, why it's not possible for Ant Home dire ? I am sorry, but I can't understand why !
Vincent please check my comments of 2003-11-18. I *did* try to implement a property editor when first writing the property, and it was very evil so I removed it. Could be fixed but probably requires some tricks from property sheet and some work to implement, TBD.
OK. Now I rereaded what you said, play with it, and finally understanded the problem. So, I propose another approach: an intermediate dialog box. I will try to summarize the idea here and attach a more detailled document: You transform that properties editor as a ListBox. By default the listbox contains only the Ant home integrated with netbeans. When the user click on the ... He see a dialog box where the ant home integrated with netbeans is displayed by default. At the right, he can see the Add / Remove / Modify / Set Default Buttons. If user clicks on Add, he has to give a name and select a directory. When he click ok. You check if it's a validate Ant home directory. When user click on Remove, you removed it of the list. When user click on Modify, he can change the displayed name and/or the directory. When user click on set default. It means that it's the default one used for all IDE. It will facilitate switch between Ant Installation because not necessary to reintroduce a complete path.
Sounds nice to me. Do you want to work on a patch for it? :-) Would just require edits to AntSettings.java and AntSettingsBeanInfo.java, I think, incl. adding some new classes for the GUI form etc. You could also use the standard ServiceType architecture, but the UI is not great there and it is not clear what the future of this design pattern is w.r.t. the Registry API. I might have time to work on this issue at some point but it is not a high priority compared to other stuff I am working on. Definitely I don't have time to do it for 3.6.
*** Issue 41379 has been marked as a duplicate of this issue. ***
Jesse, I know you asked me for a patch, but NetBeans API are too hermetics for me. Do you think you will have time for 4.0 ? Personally, I think it would be nice to do it for 4.0 because in 4.0, we have in Tools a Palette Manager, a Java Platform Manager, a Library Manager. A Ant Manager, with possibilty to switch easily between them, would be nice.
Too late for 4.0; past feature freeze. Only bugs are being fixed now.
*** Issue 57088 has been marked as a duplicate of this issue. ***
Fixed w/ new Options dialog in 5.0.