You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by mp...@ThoughtWorks.com on 2000/06/25 23:50:05 UTC
aspectJ (was Re: [PATCH] build events)
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:
<an...@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?
> >
Re: aspectJ (was Re: [PATCH] build events)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, June 28, 2000 03:29
Subject: Re: aspectJ (was Re: [PATCH] build events)
> <rant about="Microsoft C#">
> C# is the most incredibly obvious Java-clone in existance. They claim it
> was invented only with experience from C/C++ but do you believe that?
> They cloned everything and they even got it WRONG!! Look at namespaces,
> look at pointer availability.
It's a bit like the engineers were told to make 'an easier to use version of
C++' without being allowed to read the java manual -just being told of some
of the language features by someone in marketing who could not remember the
syntax. So things in java (instanceof, boolean, synchronized) get
equivalents with the wrong names (is, bool, lock)
Also the bits of VJ++ that nobody used (delegates) are in there, still for
no apparent reason.
> And they add _nothing_ that Java doesn't have today
1. there's goto (!)
2. even the primary types (int &c) derive from object (someone must have
read the smalltalk manual)
3. variable length arguments are permitted
4. properties can have explicit get/set operators which are not visible to
callers. (good or bad, depending upon your opinion)
5. switch statements can use strings (as opposed to the old 'Randall
maneuver ' of using weakly hased cases like case 'J'+'A'+'N')
>(well, to be honest,
> only one thing "class versioning" which is something I'd expect the JCP
> to talk about soon).
The versioning thing is actually incomplete in C# , despite its claims. The
versioning, as in COM, exists only to ensure interface compliance.
Versioning is also about implementation compliance. Given that most of the
system admin features in win2K related to DLL hell are effectively about
versioning COM libraries, one would have expected more from the langage.
Also, if VB is anything to go by, each version of the language adds new
reserved words, which kind of breaks everything if you were unlucky in your
choice of identifiers.
> </rant>
> And if it takes 2 years to get assertions and 5 years to get aspects
> into the language but only engineering and technical reasons drive that
> R&D period, I'm totally fine with that.
I suspect the battle will be less on pure language than on ease of
development and deployment. Right now java has the edge on both counts. The
C# spec does not cover those. Tools like ant, tomcat etc can help keep C#
down.
The most amusing thing, when you think of it, is that MS, bastion of VB and
the largest commercial vendor of Windows C++ compilers has effectivey
admitted that neither of them cut it in the web world -one too hard, one too
cheesy. Does C# spell an end to Win32 API, MFC and ATL? we shall have to
see.
Now, to get back to something ant related I've attached in my own Touch
task, which I'm not happy with as it does not do what I really want:-
-take in a list of files
-take a timestamp from a) another file b) remote sources and c) text
parameters
It probably raises an exception on jdk1.1, but I havent tested that.
-Steve
RE: C# (was: aspectJ (was Re: [PATCH] build events))
Posted by Paulo Gaspar <Pa...@krankikom.de>.
Yeah, I would call it "C pound" or "C heavy" instead of "C sharp".
It is not that small and simple anyway.
But, it is not just a Java inspirde language. It has Delphi
influences too:
- In Delphi one must use the "override" (instead of "overrides")
keyword to override a method, making the overrideing explicit. Of
course that M$ never mentions Delphi on their pages and only
compares that feature to Java and C++ in the front marketing page;
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp
- The "using" (to use a module) is quite similar to the "uses"
keyword in name and functionality. "Uses" is already old Borland
Turbo Pascal stuff (version 4);
- and the indexed properties... etc.
That influence is obvious too, since the architect of C# (Anders
Hejlsberg) was part of the initial Delphi team.
And the Delphi team sure knew Java since the start, as it gets obvious
by analizing some of the language features - like interfaces and
interface inheritance, that are similar even in declaration syntax
(the inheritance declaration, I mean).
Anyway, a competent language designer usualy knows many languages.
And I even like the language as having several improvements over C++,
Object Pascal and, arguably (because of low level stuff being
possible) Java. (Althought I would not allow any implicit type
conversions, even if declared).
Of course that you CAN NOT expect platform independence from M$.
Especially, you can not expect independence from COM/ActiveX. That
was the start of the end of Java in M$, remember?
Have fun,
Paulo
(paulo.gaspar@krankikom.de)
-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Wednesday, June 28, 2000 12:29 PM
To: ant-dev@jakarta.apache.org
Subject: Re: aspectJ (was Re: [PATCH] build events)
<rant about="Microsoft C#">
C# is the most incredibly obvious Java-clone in existance. They claim it
was invented only with experience from C/C++ but do you believe that?
They cloned everything and they even got it WRONG!! Look at namespaces,
look at pointer availability.
C# is the ultimate macro virus language. They have no notion of
security, no notion of sandboxing, no notion of platform abstraction (of
course not!).
And they add _nothing_ that Java doesn't have today (well, to be honest,
only one thing "class versioning" which is something I'd expect the JCP
to talk about soon).
</rant>
Re: aspectJ (was Re: [PATCH] build events)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 6/28/00 3:29 AM, Stefano Mazzocchi at stefano@apache.org wrote:
> I'm _very_ worried about Sun marketoids willing to add new syntactical
> sugar to Java to match C# additions.
Don't worry... The marketing people can change the name, but they have a
hard time changing the tech (unless they stage a coup, in which case I might
have to change email addresses. :)
.duncan
Re: aspectJ (was Re: [PATCH] build events)
Posted by Stefano Mazzocchi <st...@apache.org>.
I'll play the devil's advocate for a moment.
AspectJ is totally cool. It's really the change that would take Java to
2.0 (not Java2 marketing shit, I mean JDK 2.0)... but research on AOP
and MDCS (multi-dimensional context separation) is relatively young
compared to the software paradigms they use in Java.
The good thing about AspectJ (IMO), it's the absence of formal JCP crap
on top of it. As long as it stays separate, it evolves fast. I already
have a couple of interesting ideas on how to make the syntax more
friendly and I expect AspectJ to change a lot now that received public
acceptance and a community is created around it.
In the Apache Avalon project (as well as Cocoon) we are thinking about
using AspectJ once its syntax solidify. Avalon and Cocoon are entirely
based on "separation of concerns" and using a programming language that
enforce this futher is not good, it's vital!
Moreover, AspectJ is much simpler (IMO) than other java-related AOP/MDCS
alternatives (such as IBM HyperJ, which is simply too complex).
And then again, if it takes 5 years to enter Java mainstream, I don't
care, as long as it enters it with full engineering merit and not for
some Xerox-Sun marketing deal or some anti-C# marketing retrofight.
<rant about="Microsoft C#">
C# is the most incredibly obvious Java-clone in existance. They claim it
was invented only with experience from C/C++ but do you believe that?
They cloned everything and they even got it WRONG!! Look at namespaces,
look at pointer availability.
C# is the ultimate macro virus language. They have no notion of
security, no notion of sandboxing, no notion of platform abstraction (of
course not!).
And they add _nothing_ that Java doesn't have today (well, to be honest,
only one thing "class versioning" which is something I'd expect the JCP
to talk about soon).
</rant>
I'm _very_ worried about Sun marketoids willing to add new syntactical
sugar to Java to match C# additions.
But if this happens, people, Apache is in the JCP EC and I'll make sure
we _block_ any of those stupid marketing-driven actions. Java is ours.
It's from engineers to engieneers. We won't let them pollute it with
crap.
And if it takes 2 years to get assertions and 5 years to get aspects
into the language but only engineering and technical reasons drive that
R&D period, I'm totally fine with that.
It would be much worse to add aspects to java to shift the attention
from C# to Java#
Duncan, please, make sure these strange ideas don't percolate to the
top. James is my best viral vector for introducing ideas into Sun's
blood vessels :)
James Todd wrote:
>
> 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:
> > <an...@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?
> > > >
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: aspectJ (was Re: [PATCH] build events)
Posted by James Todd <jw...@pacbell.net>.
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:
> <an...@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?
> > >