RE: [aspectj-dev] RE: AJDT 1.1 up and running :-) One small weaver bug r

["Mik Kersten" <mik@xxxxxxxxxxxxxx>]

Thanks, I've added this to the Bugzilla.

We need to have a release of AJDT ready by midnight PST in order to make the
AOSD Eclipse BoF CDs printing deadline.  We were planning of making this a
full b5 release, and Adrian has been leading the corresponding testing.

However, some incremental compilation related tests are failing.  We don't
need the incremental compilation to be working for the b5 release of AJDT,
but probably shouldn't release the command line compiler that way.  Also,
there are still 5 outstanding P2 bugs.  

We really need to have the latest updates to AJDT on the CD because it is
working considerably better than 1.0.6 and supports Eclipse 2.1.  So if you
have time to try and get the command-line compiler into a releasable state
today, let us know.  Otherwise, I think that we need to package AJDT as
1.1b5, and include AspectJ 1.0.6 and 1.1b4 on the CD.  In order to keep
future bug reports from getting confusing this probably means that the next
release of the compiler should be b6.

Let me know what you think.

Mik

> -----Original Message-----
> From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx]
> On Behalf Of Jim.Hugunin@xxxxxxxx
> Sent: Wednesday, February 26, 2003 5:47 PM
> To: adrian_colyer@xxxxxxxxxx; ajdt-dev@xxxxxxxxxxxxxxx
> Cc: aspectj-dev@xxxxxxxxxxx
> Subject: [aspectj-dev] RE: AJDT 1.1 up and running :-) One small weaver
> bug remains
> 
> Adrian Colyer wrote:
> > ...- there's one thing in the weaver I
> > couldn't solve tonight (Jim/Mik) : org.aspectj.weaver.Checker.match(..)
> is
> > called when checking whether a declare warning /error pointcut matches a
> > given shadow. If t does, a Message is created whose sourceLocation is
> > shadow.getSourceLocation(). The implementation of getSourceLocation in
> > BcelShadow returns the unqualified file name rather than the qualified
> one
> > (e.g "Point.java" rather than
> > "org.eclipse.ajdt.demo/src/figures/Point.java") which means that later
> on
> > eclipse can't find the resource the marker is supposed to be attached
> to.
> > I've patched it in AJDT by scanning the project for the first resource
> > that
> > ends in the given name and using that, which we will get away with for
> > many
> > projects. I couldn't find an easy way to fix it properly in the weaver.
> 
> This is an issue with the weaver operating on bytecode, where the only
> information about the actual source file is the FILENAME attribute in the
> .class file which just contains the final unqualified portion of the name.
> I can think of three solutions to this:
> 
> 1. Change the code for getSourceLocation to use the current package in
> order to produce a more complete filename, i.e. figures/Point.java instead
> of just Point.java.  This should be a relatively straightforward and
> localized change and is the only solution that would help the case of
> weaving into .jar files.
> 
> 2. Pass some additional information from the eclipse compiler phase to the
> bytecode weaver to let it know the actual source locations of files.  This
> could give you the actual source file, but is a crosscutting change that
> would affect a lot of the system.
> 
> 3. Handle declare error and warning in a special pass that performs
> weaving on the AST rather than the .class file.  This is the only solution
> that will give you correct column information which can make these
> messages easier to understand, but it is a LOT of work.
> 
> I'd recommend that you consider doing #1 in order to improve the quality
> of your hack in the short-term.  I plan to look at #2 as part of a final
> clean-up of the incremental compilation code before the candidate1
> release.  I think that ultimately #3 is the right answer, but it would be
> a very large amount of work and could only happen post-1.1.
> 
> -Jim
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev