This is caused by the fact that when the build is run, all 
JSPs are parsed (this is the "finding the objects to 
compile" part). This is done to discover the JavaBeans 
that need to be compiled before the JSPs, and also to 
track information about included pages, which is later 
used by the debugger.

A short-term solution could be not to parse the JSPs, but 
this would cause the problem that when JSPs are compiled, 
not all Java classes will be up to date, thus compilation 
of JSPs could fail even if the application is correct. 
What we could do is to make this configurable and release 
this as a patch after the 3.5 release. Looking at the 
source code, this looks like a straightforward change 
(needs to be tested thoroughly, though).

A long-term solution is to take advantage of the build 
target concept in the new Projects infrastructure. JSP 
compilation could depend on the build target that builds 
all Java sources, thus no parsing would be needed.

I suggest waiving this bug for NB 3.5/Nevada, and fixing 
it in a subsequent patch release (using the short term 
fix), and in NB 4.0 (using the long term fix).

Oops, incorrect target milestone.

I would suggest that the fact that teh classes may not be current can
be notified to the user by a console message and/or assume that the
developer will rebuild the sources if he finds errors, etc. 

It is really not right to penalize those developers who build their
classes before building the JSPs. 

Additionally, the build all on JSPs will eb run only to test the
compilation status of the pages since tomcat will compile these pages
anyways when running th application. So parsing it for sources is not
a good idea.

I would suggest that this be fixed for 3.5 with teh workaround
mentioned. The developers can learn that they need to build their java
sources before building the JSPs. 

For me this is a major problem and I amy even go to the extent of
calling it a show stopper coz it forces me to go on coffee breaks
every time i want to verify if all my JSPs compile.

Navneet, how long is the time exactly for you ? What 
hardware are you running this on ?

Thanks.

Raw data (while waiting for the answer from the Navneet):

Building an app containing 87 JSPs on a Pentium 4 / 2.2GHz - it
completed in 3:30 minutes. 
Recompilation when all pages are up to date (which should complete
instantly) took 1:30 minutes. 

Using the jspc command line tool, supplied with Tomcat, compilation
takes 50s. 

Waiver approved.

Navneet, Petr will try to figure out the temporary workaround (switch)
and add the patch to this issue. Would you like to test it when available?

It will be the hack with possible side effects, so I'm hesitant to add
it to the release.

Sure i will be interested in testing the patches. 

Let me know.

Maybe yuo can add a setting somewhere saying the JSPs can be compiled
without checking for the class update status. Also mark a warning
there saying this is a test version. And set it off by default for
people who don't want to wade into that teritory.

Partial fix implemented in the trunk. Added command line option:

-J-Dnetbeans.jspcompile.shouldparse=false

When this line is specified in the $NB_INST_DIR/bin/ide.cfg file, the
compiled will not parse JSP files before compiling them. This will
speed up the compilation, although it may cause some Java classes
(beans) used by the pages to be out of date when compiling, and thus
cause compilation errors.

The fix will be available in the next daily build of the NetBeans
trunk: 200305230100 (not version 3.5).

This switch should be documented in arch document I think.

Just for completness:

http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/core/jsploader/JspCompilationInfo.java.diff?r1=1.3&r2=1.4
 
http://web.netbeans.org/source/browse/web/core/src/org/netbeans/modules/web/core/jsploader/JspDataObject.java.diff?r1=1.24&r2=1.25

The JSP compilation hs been replaced by validation, which fixes this
problem.