[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-dev] RE: AJDT 1.1 up and running :-) One small weaver bug remains
|
Mik, I'm not sure I understand why 1.1b5 is not releasable now, and
I don't think anyone is thinking of getting to 1.1 final today
(I know my stuff isn't ready.).
Some incremental compilation tests have been failing for a while,
and the P1-P2 bugs need not be fixed until final. The current tree
is an improvement over 1.1b4 and, AFAIK, has not regressed in quality
in any respect, so it's worth releasing.
I think your plan is right, to package AspectJ 1.0.6 and 1.1b5
on the CD with AJDT {whatever worked with 1.0.6} and 1.1b5.
Am I missing something?
Wes
Mik Kersten wrote:
>
> 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
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev