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 55601 - Ignore Library from scanning, Use only for compile/run
Summary: Ignore Library from scanning, Use only for compile/run
Status: RESOLVED DUPLICATE of bug 55784
Alias: None
Product: projects
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-28 11:42 UTC by kajekar
Modified: 2006-01-22 17:10 UTC (History)
1 user (show)

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 kajekar 2005-02-28 11:42:28 UTC
The Library Manager is a very very cool feature.
However, since i have a huge list of jars (most of
which I dont use directly but needed for my
program to run) NB 4.1 takes up huge amt of memory
(Win taskManager reports close to 280Mb) and it
becomes very very sluggish. Also, this adds to the
starup time because of initial scanning.
In 3.6, it was possible to have jars/classes in
the the class path but not in code completion
database by adding these jars to compiler options.
Something similar in NB 4.x would be great.
IMO NB can provide an option to ignore libraries
from scanning and from code completion. So I will
create a library called "3rdParty" or "External"
with this attribute set and put all jars which i
dont need for coding there - I am hoping this will
reduce the mem consumption and the performance of NB.
Comment 1 jessholle 2005-03-02 16:05:16 UTC
Actually I have to disagree with the thrust of this request.

I believe the solution is not to omit libraries from the code
completion database.  Rather it is to give explicit control over when
scanning is performed!

In my case I need code completion on the massive library.  Moreover, I
have to work with this library as its own massive project.  The
solution is not to cripple the IDE's code completion, refactoring, etc.

The solution *is* to let me set a project preference to skip the
automatic scanning upon opening the project and allow me to request it
when I need it!  The IDE can provide perfectly helpful code completion
without the entirety of its code completion database being perfectly
up to date!  For refactoring, a simple "Metadata database may not be
up to date.  Update now?  OK/Cancel" dialog would suffice.

Currently it can take over 15 minutes for me to open my project
sometimes!  That is ludicrous for a foreground activity before I can
start working, especially when the vast majority of the time nothing
has changed since I last opened the project -- and if it has I *know*
when it has!
Comment 2 jessholle 2005-03-02 16:24:51 UTC
I have filed an alternate enhancment: 55784
Comment 3 kajekar 2005-03-02 16:34:01 UTC
I see your point.
In my case, these are jars/classes which i am not using directly and
will not effect my refactoring etc. Hence i would prefer NB not
scanning  these and loading 'em into memory. 
The reason to prevent scanning is simply to reduce memory consumption
and improve performance.
When i first tried the IDE, i added all the jars and classes folders
to a library, and the IDE was taking over 300 Megs and was very very
sluggish. And now, i have (painfully) filtered this list to only those
which i will need (directly + indirectly) and IDE is much faster. 
Hence the request. And I think library manager is just the place to
add this "knob". 
But yes, the kind of feature you need is immensly useful and much needed. 
Comment 4 Jesse Glick 2006-01-22 17:10:52 UTC
Reporter's best option is to break up the project into more manageable pieces
with more limited dependency lists - and don't open the projects which are not
actually being worked on. Or buy more RAM. A future IDE release may have a
lighter-weight scanning engine but this is going to take a while to implement
and would happen for other reasons anyway. For other possibilities see issue #55784.

*** This issue has been marked as a duplicate of 55784 ***