ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edwards, Jayme" <JCEdwa...@software.rockwell.com>
Subject RE: [NB-EAP] Exposing CVS/Custom Actions from another module on D ataLoaders
Date Tue, 25 Apr 2000 22:52:41 GMT
comments follow...

> > I needed to determine the local filename from a filesystem 
> > for passing to Ant using Apache's API and was originally 
> > casting to LocalFileSystem.
> 
> Not too good an idea because it may not work on CVS or 
> similar filesystems.
> Probably what you want is NbClassPath.toFile. This should 
> give you a local
> file if there is one to be found, and is more reliable than a cast to
> LocalFileSystem.
> 

Not a problem, have had this working since the original post, 
was just commenting on progress of the module.

> > One more thing!!!! I want to add support for locating the 
> > files in which javac errors have occurred. I am going to 
> > write some code that will try to figure out the location of 
> > your source directories relative to wherever you mounted the 
> > directory containing the Ant project file(s). Then I am going 
> > to try to figure out how to catch the filename/line number of 
> > compiler errors to allow the user to bring up the source file 
> > by double-clicking on the error in the output window (or the 
> > tab I've created - I give the user the option of building 
> > targets with or without their own tab). Can you give me any 
> > hints on how to determine whether the text in the output 
> > window was generated by javac and how to catch events fired 
> > on it when the use clicks? Any help would be excellent.
> 
> Well, there's a few different levels at which you could try 
> to do this. I
> will go in order from least work/least specific control/best 
> integration
> with normal IDE processes, to do-it-yourself.
> 
> First of all, you might want to take a look at source for the Makefile
> support module since this does something partially similar, 
> though I am not
> completely happy with the solution. Ideally if you were subclassing
> ExternalCompilerGroup (are you?) there should be some way to 
> hook into its
> handling of source file lookup; you *can* control the error 
> expression (e.g.
> Javac-style) but not the details of the lookup, such as supplying an
> alternate base directory to search from. (The default implementation
> searches for source files starting at the classpath; the 
> Makefile module
> hacks this to accommodate error messages relative to the 
> Makefile's own
> directory.) If you can make sure that the implementation code 
> in E.C.G. will
> find source files based on package and class name in your 
> setup, then it
> will automatically hyperlink the errors in the output window 
> for you. You
> then are reusing a lot of code to scan for error messages and 
> parse them.
> Note that if you are driving this stuff through the 
> compilation engine it
> creates a tab for you, there is no API call to specify a 
> different output
> tab.
> 
> If you are implementing this stuff via a compiler and are 
> using the Compiler
> API normally, then if you can figure out the FileObject 
> corresponding to a
> message by hand (possible but not all that easy if it is 
> coming from an
> external process) then fireErrorEvent may be passed that file 
> object and
> this will create a hyperlink for you. This is much easier if 
> you can control
> the details of what the compiler spits out by way of errors 
> (e.g. if the
> compiler is JVM-internal and there is a detailed API to it). 
> Otherwise you
> deal with a lot of string processing and stream handling.
> 
> If you are just bypassing the compilation system entirely, 
> creating your own
> tab, and driving the whole process manually, you can use
> OutputWriter.println(String,OutputListener) and then do 
> whatever you please
> with the generated OutputEvent's. Typically this would mean 
> something like
> taking the file object you know corresponds to the line, as 
> well as the line
> number in the file, and looking for an EditorCookie on the 
> corresponding
> DataObject, opening it, and positioning the caret at that line via
> NbDocument.findLineOffset.
> 

I would like to ask those browsing this list, what would you 
prefer to happen when an Ant target executes (if you have a 
better idea please suggest it but also select the best of these 
options):

1) All output status from the "build" (all targets) is printed to 
a tab or the output window (the module lets you pick either case) 
and only the output from "javac" tasks is hyperlinked to mounted 
source directories to allow for bringing up the line in which errors 
occur.

2) All output status from the "build" is printed to a tab or output 
window /except/ javac tasks, which are integrated into the IDE and 
use it's default processing for display of compiler output. This 
would allow the same hyperlinkage to error lines as above albeit being 
displayed in it's own context (separate from the rest of the build).

Jayme

Mime
View raw message