+++ This bug was initially created as a clone of Bug #165124 +++
NetBeans has good "Import" feature in java file and "Include" file in php file.
The worst is that Netbeans 7 does a good job with most toolkits, like Dojo, BUT ONLY IF they are put in the project dir.
I didn't find any way to put Dojo (and the others toolkits) in a root dir, so they can be referenced by many projects without duplicating everything in every project dir.
THAT IS A MUST not only for space problems, but also for maintainability: just imagine I have to do a change in 1 line and I must replicate in 20 projects! :-(
So, a simple way to cope with this HUGE design bug, is the same as Eclipse: an option to specify the paths to dirs, using that option to extend the dirs Netbeans scans to create code completions rules.
I think an expert developer of the Netbeans team can do that in 20 minutes.
PS: I'm not able to start a new bug from scratch so I used the most compatibile to start a new one.
If you put the folder with js files as one item of Include Path (project or global), it should work. Did you try it?
I tried last sunday but it works only for php not js.
I think there is an implicit filter such as *.php and that solution doesn't work for js.
I've done a workaround for linux: making a soft link in the project have the same effect as putting the real dir inside the project.
So, having prj1 with /dojo and prj2 with a php project, adding a link in prj2 such as ln -fs ../prj1/dojo, solev the problem.
The same trick doesn't apply to windows: netbeans ignores windows links.
Most commonly I would use vendor branch . Therefore I see no advantage in proposed change. Actually proposal is quite close to bad practice. I do understand that in real life one cannot always use vendor branches but nevertheless the NetBeans IDE should not encourage such practice.
Further on, I don't see why is this bug marked as P1.  At best priority can be P3. There are way much more important issues then this one.
>Actually proposal is quite close to bad practice.
Let people decide on it. This is the first time I face a product that force to have library INSIDE the project itself.
Vendor branch can be a "solution" for some cases, but not for all cases and anyway is very bad supported in Netbeans because is certainly not a good choice to degenerate, in unnatural manner, the Netbeans Project using it as a multiproject container.
Netbeans is clearly designed to have 1 folder for 1 project (that's shown by the option that relate 1 project to another).
So, the right way (used also from Eclipse, Visual Studio, and any other IDE of the universe) is
The 2nd way I suppose will also introduce a great overhead in the IDE, in that Netbeans scans everything, and also show everything in the code completion, even what I don't have to see.
Just imagine 10 projects: 2 use dojo, 2 jquery, 2 dojo + jquery, 2 YUI + jquery:
With vendor branch I should have
having to maintain 2 dojoroot and 3 jquery even if are all the same versions.
Then, when SubProj1 have to use jQuery, I have to move it under ProjVendor2.
The same under Eclipse (or even Netbeans if used with something other than JS!) would be a more simpler:
and every project use what it wants when it needs.
That's why Vendor branch is not a panacea, and that's confirmed by Netbeans itself since it don't force to use it under PHP, JAVA, C++, and so on. Only Ajax developers has to face this BUG and P1 is a good choice for a design ERROR.
I have been using this feature in Eclipse for the past years and it works realy well there.
I realy like Netbeans handling of different scopes and objects way ahead of Eclipse but this missing feature realy anoys me.
I do server side JS dev and I have a set of libraries that I use, I don't want to copy them one by one in my project, I have no interest in jQuest ExtJS and so on.
Add support for libraries. (Reported: 2007-11-19 10:47 UTC by Jan Jancura)
This thread looks to be the most recent one, so here is my use-case ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Having both options available in parallel would be excelent.