thx for the perspectives. i agree with you on all accounts ... from the coolness to the harsh realities. i had a feeling it was a compilation hog. my gut tells me that this or a similiar feature may end up in java (or javax) before 5 years time given the rate of java's adoption of "the right mix of things"... but it is't here today.
listeners are a solid investment regardless. thx again, - james [EMAIL PROTECTED] wrote: > i actually caught the aspectJ presentation at javaOne and thought it was > one of the best sessions they had this year (along with the apache ones, of > course ;). But then I actually tried it and saw how long it took to > compile our 2000 file project, and that was the end of that :( . It's > definitely very cool, though, and seems to fix a lot of the problems > associated with OOP. Hopefully performance will improve in the future. > (Has anyone out there written an "ajc" task, by any chance?) > > I agree, however, that it doesn't make sense to use it with Ant. The main > reason is that it's nice to be able to add and remove listeners at runtime. > WIth aspectJ, you need to determine which aspects to include at compile > time, which means that if you wanted to add the XmlLogger as a listener, > for example, you'd have to recompile Ant. > > I also doubt that aspects will be added to the core language any time soon. > It's taken 5 years to get assertions added... > > Matt Foemmel > ThoughtWorks, Inc. > > > James Todd > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > ll.net> cc: > Subject: Re: [PATCH] build events > 06/25/00 > 01:37 PM > Please > respond to > ant-dev > > > > <sideNote> > > at javaOne this year there was a very compelling "aspectJ/assertions" > presentation ... which used tomcat code as a case study highlighting > the benefits of aspectJ. note: this is not an endorsement of the product > aspectJ but is just a "mind expanding" tid bit. to put a long story short, > it was trivial, or so it appeared :), to take the various and what > appeared to be random "debug and logging" statements sprkinkled > within and instead, using aspectJ (and the premise of assertions), one > could instrument "externally" (before method entry and after method exit > junctures) and quite seemlessly introduce logic nodes ... all without > changing a line of code or even requiring the code for the target object. > quite compelling. > > again, i'm not advocating the use of one product or another and > further this feature may or may not be added to the java core (i > believe a jsr is underway) but none the less this just feels right to > me and as such it might be cool to "skate to where the puck is > going vs skate to where the puck is" ... if at all possible. with > enough creative "what if" thinking and bit twiddling ... who knows > what is possible. > > </sideNote> > > hope this helps, > > - james > > [EMAIL PROTECTED] wrote: > > > My thinking on the logging for Javac was that it should be the logger's > job > > to determine whether or not to break things down into separate lines. For > > example, in my XML log, i wanted to just have a single <message> element > > containing the output from javac. I'm definitely flexible on this, since > it > > means that output won't be dumped to the screen until the compile is > > finished, which people might not want. But it does give Ant the chance > to > > see whether the compile failed or not before determining whether to log > it > > as a warning or an error. > > > > Using the return code from javac instead of parsing the output stream > > should work. If you decompile sun.tools.javac.Main.main(), it checks this > > return code to see what value it should pass to System.exit(). JDK1.3 is > > slightly different in that the Main.compile() method returns an int, not > a > > boolean, but it's the same idea. I assume that the return code from the > > jikes.exe process is also accurate, or it wouldn't work with any other > make > > tools out there. So we could use the return code there as well and remove > > the JikesOutputStream if we wanted. > > > > Matt Foemmel > > ThoughtWorks, Inc. > > > > > > "Conor > > MacNeill" To: > <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED] cc: > > m> Subject: RE: [PATCH] build > events > > > > 06/24/2000 > > 05:56 AM > > Please > > respond to > > ant-dev > > > > > > > > Matt, > > > > I have now applied your build events patch with some minor mods > > > > 1. Added flag to prevent ant trying to build when project configuration > > failed or help requested > > > > 2. Added -listener to usage > > > > 3. minor comments > > > > 4. Made it work under jdk 1.1 (I left out setting the InputSource system > Id > > for this reason) > > > > I do have a few questions, however, which may be worth further > discussion. > > > > You have changed Javac to remove the need for the JavacOutputStream. The > > result is that javac output is not streamed out, but batched up in > memory. > > I > > presume that is so you can set the appropriate priority on the whole > output > > message from javac (warn or error versus info). Are people cool with > that? > > What about Jikes, modern compile, etc? > > > > The detection of whether an error occurred is now based on the javac > return > > value rather than the detection of the word "error" in the javac output > > stream. Is that behaviour of Javac guaranteed? > > > > I haven't yet added the log.xsl stylesheet. I am tossing up whether to > add > > it at the root of the ant tree or in the etc directory? ideas anyone? > > > > Conor > > > > -- > > Conor MacNeill > > Home: [EMAIL PROTECTED] > > Work: [EMAIL PROTECTED] > > Web: www.cortexebusiness.com.au > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: Monday, 19 June 2000 12:31 > > > To: [EMAIL PROTECTED] > > > Subject: [PATCH] build events > > > > > > > > > ok, here's a first attempt to add events to Ant. The basic idea is to > > keep > > > the core build engine "clean" and free of any presentation logic, and > to > > > make it easier to extend Ant with other features without cluttering up > > the > > > core. To do this, I've defined a BuildListener interface and added an > > > "addBuildListener" method to Project that can be used to register > > listener > > > objects. Listeners could be implemented to generate reports, send out > > > emails when the build is complete, create a bill of materials, etc... > > > > > > The only new functionality visible to the end-user is a "-listener" > > option > > > on the command line that will let you specify the name of a class. An > > > instance of this class will be added as a listener to the project. I've > > > included a listener that will generate an XML log file, which you can > use > > > by typing the command below. I've also included a simple stylesheet to > > > display the generated XML: > > > > > > build -listener org.apache.tools.ant.XmlLogger > > > > > > (See attached file: events.jar) > > > > > > Matt Foemmel > > > ThoughtWorks, Inc. > > > ----- Forwarded by Matthew P Foemmel/Corporate/ThoughtWorks/US on > > > 06/18/2000 05:51 AM ----- > > > > > > > > > Matthew P > > > > > > Foemmel To: > > > [EMAIL PROTECTED] > > > cc: > > > > > > 06/14/2000 Subject: build > > > events > > > 05:39 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > I've made a few changes to Ant for my project here, and I'd like some > > > feedback on whether its worth cleaning up and submitting as a patch. > > > Basically, we needed a way to generate an XML file with a summary of > what > > > errors happened during the build. To do this cleanly, I ended up > > > implementing event/listener classes so that one can add listeners to a > > > project and be notified when various things happen. The classes look > > > something like: > > > > > > public class BuildEvent extends java.util.EventObject { > > > public Project getProject(); > > > public Target getTarget(); > > > public Task getTask(); > > > public Throwable getException(); > > > public String getMessage(); > > > public int getMessageLevel(); > > > } > > > > > > public interface BuildListener extends java.util.EventListener { > > > public void buildStarted(BuildEvent event); > > > public void buildFinished(BuildEvent event); > > > > > > public void targetStarted(BuildEvent event); > > > public void targetFinished(BuildEvent event); > > > > > > public void taskStarted(BuildEvent event); > > > public void taskFinished(BuildEvent event); > > > > > > public void messageLogged(BuildEvent event); > > > } > > > > > > public class Project { > > > public void addBuildListener(BuildListener listener); > > > ... > > > } > > > > > > Then I simply defined an XmlLogger class that dumped whatever XML I > > wanted > > > into a file, and added it as a listener to the Project. I was also able > > to > > > move all of the "user interface" code for Ant (ie all of the > out.println > > > ()'s) into Main.java so that it was all in one place by making it a > > > BuildListener. The makes the rest of the code cleaner if we want to > > create > > > a gui version of Ant, say. It also makes it easy to create listeners to > > do > > > profiling, debugging, etc... > > > > > > Is this worth pursuing? > > >
