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]
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
#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:
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
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
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
* 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
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
*** Issue 137700 has been marked as a duplicate of this issue. ***