ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <jwt...@pacbell.net>
Subject Re: aspectJ (was Re: [PATCH] build events)
Date Tue, 27 Jun 2000 16:25:50 GMT

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

mpfoemme@ThoughtWorks.com 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
>                     <jwtodd@pacbe        To:     ant-dev@jakarta.apache.org
>                     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
>
> 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