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 feature is to enable the declaration of a "path variable" in the IDE, and use that declared var to specify path-like resources such as the location of a JAR file needed for compilation. Here's the Email discussion in user list: ========================= by Qingtian Wang Feb 23, 2007; 10:42am :: Rate this Message: (use ratings to moderate[?]) In both Eclipse and IntelliJ, there is this concept of "path variable" where the use links a local disk directory to a named variable in the IDE. Among other things, this makes IDE project sharing over VCS much easier. Users can just check out the project, configure the his/her value for the named variable in the IDE (in most cases, the classpath/jar location on the local machine), and off you go.... Is there something similar in NetBeans? Thanks, -Qingtian =========================================== Re: classpath Variable Click to flag this post by Grzegorz Borkowski Feb 23, 2007; 12:28pm :: Rate this Message: (use ratings to moderate[?]) Probably libraries? (Tools->Library Manager) You declare dependency on named Library, and everybody creates Library(containing jars, sources and javadocs) locally - everybody can have it in different location. =================================== Re: classpath Variable Click to flag this post by Qingtian Wang Feb 23, 2007; 12:40pm :: Rate this Message: (use ratings to moderate[?]) Library is sort of inconvenient in terms of sharing. The reason is that each user can set the lib completely different than the other. If I can have a "named var" for a path, the shared libs can be checked in to VCS and shared because other than the location where the "named var" points to, everything else under that location is same and shared. This is especially handy if you use dynamically downloadable libs, like the dependency scheme used in Maven. -Qingtian =========================================== Re: classpath Variable Click to flag this post by Karthikeyan Rajeswaran Feb 23, 2007; 12:32pm :: Rate this Message: (use ratings to moderate[?]) Also: "Tools | Options | Miscellaneous | Ant | [Manage Classpath | Manage Properties] " thanks, karthik ========================================================= Re: classpath Variable Click to flag this post by Qingtian Wang Feb 23, 2007; 01:49pm :: Rate this Message: (use ratings to moderate[?]) Thanks Karthik. That's good to know. But... still the jar file specified that way is not "first class citizen" as those in the project's class path, where you can pick and choose whether each of the jar should be included in the WAR/EAR deployables. What'd be good is that I can set a "path variable", say, "JAR_REPO" inside the IDE. And when I give the compile libs, other than browsing to the physical jar location on the disk as it is now in NetBeans, also I should be able to give the jar as "JAR_REPO/relative_path/mylib.jar". That way, things can be easily shared by introducing the "path variable" concept. I've been around quite some places as a consultant. And that works out quite well for those who uses Eclipse or IntelliJ. -Qingtian
You can define whatever properties you like in project.properties and use them in other properties, just as in Ant. There is no first-class GUI support for this currently. *** This issue has been marked as a duplicate of 89629 ***
I understand there is no first-class support for global external path variables right now. And that is exactly what this request is about: support it. This can be a compromise between full featured #89629 (which no other IDEs provide) and no support at all for global external path variable (which both Eclipse and IntelliJ provide). Hope the feature requested here is well understood - user can define global path variables that are "expandable" to create other path-like properties - path to jar, lib, resources.... e.g. Once I defined "MY_LIB_ROOT" as such a variable, whose value is "C:\pathToMyUserHome\.m2\repository", I'll be able to further define any other path-like properties by expanding "MY_LIB_ROOT" variable. i.e. project -> properties -> library -> add jar... -> ${MY_LIB_ROOT}\someFurtherPath\myLib.jar (instead of "C:\pathToMyUserHome\.m2\repository\someFurtherPath\myLib.jar"). Once we have that, if someone else checks out my project without "MY_LIB_ROOT" defined in his/her IDE, s/he will get an error that need to be resolved just as a normal reference error. I hope that is clear. And I don't think that is a full-blown duplicate of #89629. I also think it won't be too hard to implement such a feature given the kind of support that's already available with Ant as you already mentioned. However, once implemented, I do believe this feature, as a intermediate step, will provide a lot value to the users before #89629 is somehow achieved. Feature wise, it'll also narrow the gap between NetBeans and the other two IDEs in regard to this. Thanks, -Qingtian
Please see issue #44035, which will provide support for scenarios similar to what you describe, though not the same, and will be supported in the GUI. No support for GUI manipulation of path variables as such is planned, though as I wrote before you can use them already by editing property files.
I know this is a question you are not obliged to answer, but I'll give it a try: Why is this feature rejected (wont fix) right away rather than, say, give it a lower priority and give it the possibility of being implemented later? Is it the feature is lack of popularity (other IDEs have it, which says something out this....), it conflicts with the existing NetBeans architecture, or what...?
There is always the _possibility_ of doing something later; plans change. Keeping it open as an RFE with a low priority when there is no current expectation of implementing it serves no purpose. The expectation is that a different approach to solving this class of problems will go into the next NB release (was originally planned for 6.0 but had to be pulled at the last minute due to schedule nervousness).