ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "tcmits1" <tcmi...@cs.com>
Subject Re: [PATCH] build events
Date Sun, 25 Jun 2000 20:15:32 GMT
I like in general the idea of having access to these two 'events', entry and
exit of a method.   If exposed via inheritance then one must subclass, but
having external hooks may be more useful too.  One can then create systems
where each entry and exit could trigger external processes, like logger
modes, or even making a voice call to tell the person on call that the
compile finished.  <g>


----- Original Message -----
From: James Todd <jwtodd@pacbell.net>
To: <ant-dev@jakarta.apache.org>
Sent: Sunday, June 25, 2000 2:37 PM
Subject: Re: [PATCH] build events


>
> <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
>
> mpfoemme@ThoughtWorks.com 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:
<ant-dev@jakarta.apache.org>
> >                     <conor@m64.co        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: conor@m64.com
> > Work: conor@cortexebusiness.com.au
> > Web:  www.cortexebusiness.com.au
> >
> > > -----Original Message-----
> > > From: mpfoemme@ThoughtWorks.com [mailto:mpfoemme@ThoughtWorks.com]
> > > Sent: Monday, 19 June 2000 12:31
> > > To: ant-dev@jakarta.apache.org
> > > 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:
> > > ant-dev@jakarta.apache.org
> > >                                          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?
> > >
>
>


Mime
View raw message