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 58064 - Prebuild code-completion database and classpath indexing to improve long "Scanning Project classpaths"
Summary: Prebuild code-completion database and classpath indexing to improve long "Sca...
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-19 20:30 UTC by _ potingwu
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
bigger log file for java.io.FileNotFoundException (10.92 KB, text/plain)
2005-08-12 04:19 UTC, _ potingwu 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ potingwu 2005-04-19 20:30:02 UTC 
To improve the long "Scanning Project classpaths", NetBeans currently only
allows users/developers prebuild JDK rt.jar and src.zip with a very strict
extentName checking. It's very difficult and impossible for the developers to
prebuild these database where the target jar/zip files will be installed in
different location.

There are 2 kinds of support developers need:
* JDK/Jar prebuild database: Since 3rd party usually bundles with its own
JDK/Jar, if the target jar/zip files are under "jar:nbinst://.." directory, then
the extentName checking can be loosen by just checking the basename instead of
the full pathname. E.g., src.btd can be used by jar:nbinst://../java/src.zip.

* Branding prebuild database: Developers may create many big jar/zip files that
would like their database been prebuild. If the prebuild database files are
located in the same directory, then NetBeans should loosen the extentName
checking. This approach will also ease the patch process when releasing new
jar/zip files. E.g., jsf.btd is in the same directory as jsf.jar.

For this, the storagebuilder under java module should not just involve to
prebuild only JDK rt.jar and src.zip files. And an external executable should be
created under the bin directory for users/developers to use.

Rechecking/rescanning should be also loosen when the target jar/zip files are
under "jar:nbinst://.." directory to improve the performance.
Comment 1 _ potingwu 2005-04-19 22:43:17 UTC 
Besides, NetBeans should add a new Ant task for individual module to
automatically prebuild the database during the build so that they can release
the database files with their jar/zip files together.
Comment 2 Martin Matula 2005-06-29 17:03:29 UTC 
I've generalized the building of storage files.
Now besides the JDK paths, you can also send names of other jars and zips you
want to scan (on the commandline to the storagebuilder - see main.sh).
I also added prebuildJars() public method to the storagebuilder.Main class which
gives you even more control over the scanning (see the method javadoc).

Checking in javacore/src/org/netbeans/modules/javacore/JMManager.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v  <-- 
JMManager.java
new revision: 1.113; previous revision: 1.112
done
Checking in storagebuilder/build.xml;
/cvs/java/storagebuilder/build.xml,v  <--  build.xml
new revision: 1.3; previous revision: 1.2
done
Checking in storagebuilder/main.sh;
/cvs/java/storagebuilder/main.sh,v  <--  main.sh
new revision: 1.6; previous revision: 1.5
done
Checking in storagebuilder/nbproject/genfiles.properties;
/cvs/java/storagebuilder/nbproject/genfiles.properties,v  <--  genfiles.properties
new revision: 1.3; previous revision: 1.2
done
Checking in storagebuilder/src/org/netbeans/lib/java/storagebuilder/Main.java;
/cvs/java/storagebuilder/src/org/netbeans/lib/java/storagebuilder/Main.java,v 
<--  Main.java
new revision: 1.19; previous revision: 1.18
done
Comment 3 _ potingwu 2005-08-12 04:19:28 UTC 
Created attachment 23737 [details]
bigger log file for java.io.FileNotFoundException
Comment 4 _ potingwu 2005-08-12 04:23:01 UTC 
After using the new storagebuilder, many users report JMManager error like this:

> copyStorage failed:
D:\home-mks\main\src\ravebuild\rave\rave2.0\mdrstorage\jsf-api-dt-505527592507263c6adcfdcd4119e6f2.b
> td (The system cannot find the file specified)
> java.io.FileNotFoundException:
D:\home-mks\main\src\ravebuild\rave\rave2.0\mdrstorage\jsf-api-dt-505527592507263c6adcfdc
> d4119e6f2.btd (The system cannot find the file specified)
>        at java.io.FileInputStream.open(Native Method)
>        at java.io.FileInputStream.<init>(FileInputStream.java:106)
>        at org.netbeans.modules.javacore.JMManager.copyStorage(JMManager.java:1486)
>        at
org.netbeans.modules.javacore.JMManager.usePreparsed(JMManager.java:1535)
>        at
org.netbeans.modules.javacore.JMManager.resolveCPRoot(JMManager.java:895)
>        at
org.netbeans.modules.javacore.JMManager.resolveCodebases(JMManager.java:794)
>        at org.netbeans.modules.javacore.JMManager$2.run(JMManager.java:748)
>        at org.openide.util.Task.run(Task.java:189)
>        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:330)
>        at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:721)
> 
> The actual file I have in my build dir is named as follows:
> jsf-api-dt-371c77b83971e0dfec21a60e831f91a9.btd
>
Comment 5 Martin Matula 2005-08-12 14:14:58 UTC 
The exception is harmless (it is just printed to the log/console) -> lowering
priority. It happens if the user has a jar of the same name as the jar that is
in the build dir (i.e. was pre-parsed by the storage builder), but has a
different content (i.e. the checksum of the file does not match the checksum of
the pre-parsed file). I will fix this to supress the output in the console. I
cannot fix the fact that the files are different.
Comment 6 Martin Matula 2005-08-12 14:30:19 UTC 
Fixed.

Checking in src/org/netbeans/modules/javacore/JMManager.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v  <-- 
JMManager.java
new revision: 1.117; previous revision: 1.116
done
Comment 7 Quality Engineering 2007-09-20 09:46:12 UTC 
Reorganization of java component