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

[Lesiecki Nicholas <ndlesiecki@xxxxxxxxx>]

Another Beta would be great as 1.1b4 has a lot of bugs and at this point a
new beta would helo bug-reporters (like myself) not report things that are
already fixed in development. (Without building from source/)

Cheers,
Nick
--- Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 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
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/