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.
While working on Eclipse import I stumbled over %SUBJ% and decided to have a look how easy/difficult would it be to fix. It was surprisingly easy and so I put together above Wiki page and would like to ask you for opinion. The main questions are: * is it something we want to support? * is UI acceptable? Jano? * should core of this implementation reside in Ant project? I will attach diff with my current impl.
Created attachment 62393 [details] diff
Created attachment 62395 [details] diff (replaces previous one)
For the UI, I'm thinking how to do differently the "Add Variable" button, which is a bit strange next to "Add JAR/Folder" as the user doesn't want to add a variable to classpath. The user really wants to add a JAR that's referenced underneath a folder defined by a variable. Maybe the variables should be somehow integrated into the existing "Add JAR/Folder" chooser. Something like: (o) Use Relative Path to Variable: ... ( ) Use Relative Path: ... ... This way the user browses for a JAR file located on a regular place on disk and just tells the IDE to store it relative against a defined variable. That would be the default option if the user browses for a file underneath a defined variable.
I agree with Jano - I was just in the middle of writing a comment along the same lines!
I do agree that user is not adding "variable" but JAR/Folder. The solution Jano suggests - enhance existing filechooser accessory - resolves the problem and makes it even easier to implement. Possible disadvantage is discoverability of IDE Variables feature - until user defines some variable the option is not usable and there is nothing in filechooser which would help user to figure out how/where to setup variables. This could be amended, e.g. #1) word "Variable" in file chooser accessory could be a link either giving user a help or directly opening Variables Manager; or #2) if no variable is setup in IDE then (o) Use Relative Path to Variable: ... could be changed to (o) [Setup a Variable] where [Setup a Variable] is button opening Variables Manager; or #3) permanently show button labelled "..." after path preview field: (o) Use Relative Path to Variable: [_MAVEN/some/a.jar_______________] [...] where button (always enabled) would open Variables Manager again (and radio and path preview fields would be disabled if no suitable variable was found for selected path). OK, I believe this can be resolved so I will change my prototype to use file chooser accessory and let you know how it is going. Jano, could you please comment on above UI enhancements? TomasZ, MilanK, do you have any objections or are you OK if I go ahead and fix J2SE/Web/J2EE projects? If there should be a controversy around UI I would like to split the solution into two phases: * phase1: just code changes in project type internals which "tolerate" usage of IDE variables in projects and project customizer does not clobber them * phase2: IDE variables are supported in UI I would like to get phase1 to trunk early next week. phase2 depends on progress of UI discussion. Thanks for your comments, -D
One more question: Maven repository is usually located in you home directory in ".m2" folder which is hidden. Bear in mind that I'm Ubuntu Unix novice but I was surprised that in "Add JAR/Folder" JFileChooser I cannot browse into hidden folders? Is it an intentional? Calling "jFileChooserInstance.setFileHidingEnabled(false);" shows hidden files. Should not this option be by default set on all file choosers in NB? Without that users cannot really use Add JAR/Folders from Maven repo.
Wiki was updated with Jano's suggestion and UI enhancement #3 which I found the most practical. The user's flow is now quite straightforward: right click project's Libraries Node -> Add JAR/Folder -> browse to a JAR -> (optionally) click "..." and setup a variable -> select "Use Relative Path to Variable" -> press OK. In terms of UI (IMO) it is way better then what eclipse provides. JFileChooser is becoming little bit too cluttered but I think it is still justifiable by benefits it provides.
A few more comments: The chooser dialog should remember selected checkbox (ideally even after IDE restart). Maybe it does it. The ellipsis button (...) may give impression it's possible to _select_ variable as a base for the relative path. In this case the suitable variable is selected automatically, correct? I don't know how to indicate it's automatic and the manage dialog just manages variables. Maybe it should just let the user select variable? In the former UI proposal it was actually possible. I don't want to over-design it, I'm just thinking how to make it obvious how it works.
Re. "The chooser dialog should remember selected checkbox (ideally even after IDE restart). Maybe it does it." - default radio button should be selected according to context. That was original idea but I'm not sure if it was implemented. The rules for selection should be in this order: * if a file selected in filechooser is collocated with project then select "use relative path"; or * if selected file can be referred via a variable then preselect "use relative to variable"; or * if project has libraries folder preselect "copy to lib folder"; or * select use absolute path Re. "The ellipsis button (...) may give impression it's possible to _select_ variable" - yes it may. What about replacing ellipsis with an icon or a short word like 'Edit'? Re. "In this case the suitable variable is selected automatically, correct?" - yes. Preview field is either empty or suitable (closest) variable is shown with resulting relative path Re. "I'm just thinking how to make it obvious how it works." - I know. The thing is that ellipsis might be interpreted as selection but trying it once will make it clear it is not. If you already have a variable then it is auto preselected and user should not have a need to click ellipsis. If variable is not defined then clicking ellipsis and creating a variable (assuming with location above currently selected file) will "select" the variable - I mean after coming back from Manage Variables the filechooser's UI is refreshed and "Use Relative Path to Variable" will be initialized with the variable you just created. Of course if user created a variable not related to current path nothing happens. Also if they select a variable with unrelated path in Manage Variable and expect it to be used in filechooser nothing will happen again which sort of make sense - the paths are not related. I'm tempted to believe that it's self explainable. :-) But I'm known for being optimist. :-)
Okay, let's go with it and we'll see. A few more thoughts: It may not be obvious a variable needs to be "parent" of the selected JAR. I mean if you look at your screenshot the "Use Relative Path" value points outside of the project folder like this "../../etc.", so it may seem like something similar is possible with variables. So if the user defines a variable just to try it out, it would do nothing after closing the dialog if he didn't select parent path for the variable. Maybe we shouldn't use the term Relative Path. How about this: --- ( ) Use Relative Path ... (o) Use Variable Path |_<no suitable variable>_| [...] ( ) --- Maybe I'm just too pessimistic. ;-)
Thanks Jano. I do value your suggestions. They clearly improved UI I originally proposed and I'm very happy to follow them. -D
I don't have any objections against implementing this UI enhancement.
Created attachment 62550 [details] API changes in project.ant module + implementation
Please review small API enhancement in project.ant module (latest attachment): * existing custom FileChooser was enhanced to show new option "Use Variable Path" in its accessory and this option can be disabled * new method added for showing variables manager (will be used from broken references resolver in java.project module) * action added to Tools menu to show variable manager The UI for this enhancement (if needed) is in URL field of this issue. Thanks in advance for any comments or suggestions, -David.
If there are no objections I would go ahead and deliver the API and UI change on Thursday or Friday.
Feature delivered as: 7f80bf59b43d TomasZ, Jesse, if you encounter some problems or got an issue related to my changes, please assign it to me and I will fix ASAP. Thanks, -D
Feature ad added to http://wiki.netbeans.org/NewAndNoteWorthyMilestone1NB65
*** Issue 137700 has been marked as a duplicate of this issue. ***