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.
Summary: | allow using "path variable" to specify compile/build libraries | ||
---|---|---|---|
Product: | projects | Reporter: | wqtnetbeans <wqtnetbeans> |
Component: | Generic Infrastructure | Assignee: | Milos Kleint <mkleint> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
wqtnetbeans
2007-02-24 01:22:50 UTC
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). |