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.
I have a webapp with the following file structure: /file1.jsp /file2.jspf file1.jsp includes file2.jspf. I added some bad code to file2.jspf: FolderTab tabs[] = new FolderTab[] { new FolderTab("General","tab_general","submitToTab('tab_general');","FolderTab"); }; Compiling it yields an error: Compiling 1 source file to C:\Data\Projects\Corporate Directory\Netbeans Project\build\generated\classes C:\Data\Projects\Corporate Directory\Netbeans Project\build\generated\src\org\apache\jsp\user_005fmaint\general_jsp.java:463: '}' expected new FolderTab("General","tab_general","submitToTab('tab_general');","FolderTab"); I made the correction (verified in a separate file) to read: FolderTab tabs[] = new FolderTab[] { new FolderTab("General","tab_general","submitToTab('tab_general');","FolderTab") }; However, recompiling file1.jsp, I get the same error. I double checked my jspf and jsp file. Saved again and again, yet, when I look into the depths of the "generated" file1_jsp.java, it reflects the old code, which has been since removed. I suspect removing the "generated" files will fix the problem, but I haven't the time to verify.
This 'bug' is caused by JSP 2.0 specification, section 1.10.3: "A JSP container can include a mechanism for being notified if an included file changes, so the container can recompile the JSP page. However, the JSP 2.0 specification does not have a way of directing the JSP container that included files have changed." Thus, Jasper from Tomcat (which is used by IDE for jsp compilation) doesn't care about changes in included files. It has been already filed as part of issue 48706. Workaround is: clean the project before compilation. Marking as Wontfix since we can't hardly do anything with it. You can try file this bug to Tomcat/Jasper.
Sounds like a reasonable explanation. Perhaps we can add the feature to "clean" just a subdirectory within a project? I try to avoid the clean and build command since I have tons of source files, JSP's, beans, etc. Thanks!
Well I did some tests - this behavior occures only with compilation of JSPs within IDE. If you run the project, Tomcat notices the changes of included JSPF and recompiles it automatically. From this point of view the 'clean directory' solution wouldn't help :(. Martine, could you please ask Jasper guys, what's the difference?
I found the problem. We are not setting "development" property to true for jasper when compiling from IDE. I'll fix it.
Well, from what I've learned so far, it seems that jasper-compiler is not able to resolve dependencies when invoked outside of the container. So I must say we may not be probably able to fix this at least for 4.0. Sorry about that. I'm working with some Tomcat guys to try to find a solution, but besides that, I think we should try to find at least some partial workaround for this, so any ideas are welcomed. Currently it doesn't work even when you compile a single jsp. We could probably do some hack and try to delete the generated .class file for that jsp and then compile - that would trigger whole compilation with dependants - so that would help in single-compilation case. But what to do in Build project? I think in terms of speed, some gain can be achieved via deleting all generated .class files. That would trigger only recompilation of all jsps, so other classes do not have to be recompiled. Of course, jsp compilation is the slower part here. Any opinions and ideas are welcome.
A possible fix could be the following: the IDE keeps track of interdependencies between statically included pages. If an included page segment is changed, the IDE will "touch" all pages which include this subpage, i.e. increase the last modified timestamp of the file to the current system time. This will trigger recompilation in the JSP engine. The disadvantage of this approach is that it will confuse most CVS clients, which will think the page was modified against the checked out version.
I've combined the two approaches, so solution for the main problem that could not be easily workarounded (compilation of a single jsp) - is that if any of the included pages is changed, the corresponding class/java files from generated/src dir are deleted and this forces jasper to invoke full recompilation. I'll commit the fix into cvs tomorrow. Full project build is a different story - to check all the includes we would have to parse all the jsp files, which would introduce quite a big performance overhead, and in some specific cases it could be very slow, so I'd suggest workaround here - you may tweak the build.xml to always delete generated/src directory before building project. We may introduce some expert project property for this in future releases, too.
Single compilation problem is fixed in trunk: Checking in src/org/netbeans/modules/web/project/WebActionProvider.java; /cvs/web/project/src/org/netbeans/modules/web/project/WebActionProvider.java,v <-- WebActionProvider.java new revision: 1.42; previous revision: 1.41 done Processing log script arguments... More commits to come... Checking in nbproject/project.xml; /cvs/web/project/nbproject/project.xml,v <-- project.xml new revision: 1.15; previous revision: 1.14 done Processing log script arguments... More commits to come... RCS file: /cvs/web/project/src/org/netbeans/modules/web/project/parser/JspNameUtil.java,v done Checking in src/org/netbeans/modules/web/project/parser/JspNameUtil.java; /cvs/web/project/src/org/netbeans/modules/web/project/parser/JspNameUtil.java,v <-- JspNameUtil.java initial revision: 1.1 done RCS file: /cvs/web/project/src/org/netbeans/modules/web/project/parser/ParserWebModule.java,v done Checking in src/org/netbeans/modules/web/project/parser/ParserWebModule.java; /cvs/web/project/src/org/netbeans/modules/web/project/parser/ParserWebModule.java,v <-- ParserWebModule.java initial revision: 1.1 done So downgrading to P3 and setting target milestone to future.
I did not see any complaints about this lately, changing priority to P4.
Closing as this issue is based on NetBeans 4.0 (and fix has been committed)