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.

Bug 136516 - support user defined variables in Ant based project types as first class citizens
Summary: support user defined variables in Ant based project types as first class citi...
Alias: None
Product: projects
Classification: Unclassified
Component: Ant Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Konecny
Depends on:
Reported: 2008-06-05 00:03 UTC by David Konecny
Modified: 2008-06-23 09:56 UTC (History)
8 users (show)

See Also:
Exception Reporter:

diff (87.87 KB, text/plain)
2008-06-05 00:09 UTC, David Konecny
diff (replaces previous one) (86.36 KB, text/plain)
2008-06-05 01:30 UTC, David Konecny
API changes in project.ant module + implementation (74.63 KB, text/plain)
2008-06-09 11:05 UTC, David Konecny

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2008-06-05 00:03:52 UTC
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.
Comment 1 David Konecny 2008-06-05 00:09:51 UTC
Created attachment 62393 [details]
Comment 2 David Konecny 2008-06-05 01:30:34 UTC
Created attachment 62395 [details]
diff (replaces previous one)
Comment 3 jrojcek 2008-06-05 16:04:09 UTC
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.
Comment 4 Petr Jiricka 2008-06-05 16:13:55 UTC
I agree with Jano - I was just in the middle of writing a comment along the same lines!
Comment 5 David Konecny 2008-06-06 00:24:21 UTC
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
Comment 6 David Konecny 2008-06-06 00:32:01 UTC
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.
Comment 7 David Konecny 2008-06-06 02:34:59 UTC
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.
Comment 8 jrojcek 2008-06-06 09:48:23 UTC
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.
Comment 9 David Konecny 2008-06-06 12:57:53 UTC
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. :-)
Comment 10 jrojcek 2008-06-06 14:24:31 UTC
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. ;-)
Comment 11 David Konecny 2008-06-08 21:56:22 UTC
Thanks Jano. I do value your suggestions. They clearly improved UI I originally proposed and I'm very happy to follow
them. -D
Comment 12 Milan Kubec 2008-06-09 08:18:04 UTC
I don't have any objections against implementing this UI enhancement.
Comment 13 David Konecny 2008-06-09 11:05:46 UTC
Created attachment 62550 [details]
API changes in project.ant module + implementation
Comment 14 David Konecny 2008-06-09 11:16:46 UTC
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.
Comment 15 David Konecny 2008-06-11 11:13:48 UTC
If there are no objections I would go ahead and deliver the API and UI change on Thursday or Friday.
Comment 16 David Konecny 2008-06-13 00:51:41 UTC
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
Comment 17 David Konecny 2008-06-13 01:17:31 UTC
Feature ad added to
Comment 18 Milos Kleint 2008-06-23 09:56:10 UTC
*** Issue 137700 has been marked as a duplicate of this issue. ***