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.
Currently, Ant module has some hardcoded support for parsing Java compilation error messages and displaying hyperlinks to source. Equivalent functionality is needed in the area of JSP error messages in order to implement feature 40215. I am attaching a patch which implements error parsing for JSPs. Jesse, could you please review the patch and comment on it? Notes about the implementation: The part which parses the error message is quite straightforward. There are changes expected in this area because of some recent Tomcat fixes (initiated by us) which have not made it to a stable Tomcat release yet, but this should be easy to change. The more tricky part is finding the file in which the error occurred. The Tomcat JSP compiler only prints the context-relative path of the JSP, so if there are multiple web modules in the IDE, we need to choose the correct one. To do this, a dependency on the webapi module was added. Next, we need to use a hack similar to the Java classpath hack to find the module. For now, a heuristic is employed that looks at the Ant basedir directory, and finds a web module for that (this assumes that there may only be one docroot directory per project). A better solution would be if the JSP compiler task fired a build event which contains the web module root. I plan to work with the Tomcat team to implement this enhancement in the JSP compiler.
Created attachment 14645 [details] Patch for the Ant module to parse JSP compiler errors
Sorry, I can't accept a patch like this... a dependency from the ant module on web/* is unacceptable architecturally. (The stack trace parsing hack applies to any Java process run, even Ant tasks unrelated to Java development; it is a different case.) Furthermore, the technique for guessing at the web module root is too weak to be useful, if you consider external source root support and freeform project support. If you really can't fix your task to produce absolute filenames, it will be necessary to have some more general way of plugging in foreign Ant output parser components that can cooperate in generating hyperlinks (or at least mapping messages to filenames). So I am considering this an additional use case for issue #42525. *** This issue has been marked as a duplicate of 42525 ***
I should point out that "Currently, Ant module has some hardcoded support for parsing Java compilation error messages and displaying hyperlinks to source." is not correct. The Ant module has hardcoded support for parsing *any* error message in the normal error message format, i.e. <absolute-file-path>[:<line1>[:<col1>[:<line2>:<col2>]]][:<message>] which applies to far more things than Java compilation. Any Ant task which produces error messages is expected to use this format, or the task is buggy.
> a dependency from the ant module on web/* is unacceptable > architecturally. (The stack trace > parsing hack applies to any Java process run, even Ant tasks > unrelated to Java development; it is a different case.) Well, the Java API dependency may be there for a different purpose, but the result is still the same: the dependency is there. I don't see how Web API dependency is any worse than Java API dependency, these two APIs are at the same level. > Furthermore, the technique for guessing at the web module root is too > weak to be useful Agreed, I am working with the Tomcat team on a better approach that would be implemented during the Promo D cycle. > Ant module has some hardcoded support for parsing Java > compilation error messages Sorry, I meant stack traces, not compilation errors. > Any Ant task which produces error messages is expected to use this > format, or the task is buggy. Really? I didn't know this. Could you please point me to documentation than describes the standard error message format? Thanks. > If you really can't fix your task to produce absolute filenames This by itself is not sufficient. The thing is, the real source that wer want to show in the editor is not the same as the source that is being compiled. The JSP source is first copied into a build location and then compiled - this is a generally accepted web application development practice, not something we made up. So in order to map back from the copy to the original source location, some additional "oracle" is needed. > it will be necessary to have some more general way of plugging in > foreign Ant output parser components that can cooperate in > generating hyperlinks (or at least mapping messages to filenames). I'll think about this and about the solution for 42525. My opinion continues to be though that if this general mechanism is not implementable for Promotion D, having the dependency on webapi is an acceptable solution for D.
There's no documentation for the "normal" format for error messages because it is so conventional. Java compilers produce it, Ant's Location produces it, etc. Emacs parses it... the use of column numbers is not widespread but Jikes does it (+E or "Emacs" mode) and it is invaluable (much better than javac's error reporting).