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 96488 - allow using "path variable" to specify compile/build libraries
Summary: allow using "path variable" to specify compile/build libraries
Status: RESOLVED WONTFIX
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-24 01:22 UTC by wqtnetbeans
Modified: 2007-08-21 17:26 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wqtnetbeans 2007-02-24 01:22:50 UTC
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
Comment 1 Jesse Glick 2007-02-25 22:12:52 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 ***
Comment 2 wqtnetbeans 2007-08-21 03:52:14 UTC
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

Comment 3 Jesse Glick 2007-08-21 04:38:56 UTC
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.
Comment 4 wqtnetbeans 2007-08-21 17:08:03 UTC
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...?

 
Comment 5 Jesse Glick 2007-08-21 17:26:29 UTC
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).