Re: [ajdt-dev] AspectJ / AJDT -- what is stable?

[prg@xxxxxxxxxxxxxxx]

Hi Andy,

thanks for your quick response and the explanations; basically I am
aware of the situation and appreciate your efforts.

> If I were you, and you are happy with AspectJ 163 - I would continue
> to use that as the released stable version.  I'm suprised you didn't
> see any of the problems we had raised about JDT weaving and AJDT1.6.2
> - did you really find that a smooth experience?

Compared with the versions *before* AJDT 162, this release felt a good
deal more stable for me, especially the incremental build and the eager
parser seemed to work more smooth. Generally speaking, AJDT works rather
half-way satisfactory for us, but it has been improved significantly
since Spring 2008.

I don't know what the point of reference is for a "smooth experience".
But at least in this new AJDT 163, I saw for the first time an
(in-project) Aspect show up in the search list of "open type", while
another Aspect from a neighbour project imported via Jar at least shows
up as Class! Thanks for that! But, on the other hand, since at least
last Fall, the cross references view is unreliable, and this got
significantly worse with AJDT 162. But this is really difficult to track
down; I didn't succeed with extracting a test case showing the problem
(otherwise I'd reported already ;-)

> This is the build you want
http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectj-DEVELOPMENT-20090106235947.jar

Thanks, this is vital information for us.

I should shortly point out the situation. We have several projects,
which get deployed onto several production systems. (Financial/Banking
context). There is a formal testing and release cycle, so we can't just
take on a new AspectJ version just because it makes AJDT more smooth.

We have a strict policy that all builds need to work completely
standalone with Ant from command line, and in our setup we need to
use both aspectpath and inpath, because also our basic library jars
contain some vital aspects. Classes get rewoven, signed for web
distribution and so on. So, there are almost all the time classes
included somehow, which get woven in an external build process,
probably this also explains the sometimes shaky behaviour of AJDT.

As we have to do continuously small improvements and fixes for
production, it is really hard to get most of the team members
to upgrade for a new release cycle. We are still using AspectJ 153
in production. So my only hope is to find out a new version, which
doesn't cause compilation or memory problems and also would allow
to get all team members to use a single fixed AJDT version in near
future, which works reasonably well. (and AJ 163 looked quite good
for me up to now).



> The key problem for you seems to be for us to resolve this new issue:
...
> which I have never seen before.  Send me an email with any more info
> you have.  I'll be taking a look right now to see what it is.

In the current situation, I can reproduce it easily; I will now install
the new AspectJ driver you pointed out to me and then try to recompile
everything from scratch and re-build all jars. I'll report the outcome
of this check immediately, say in about half an hour.


The Aspect which is probably causing it is a well known culprit.
Probably I wouldn't do it again this way, but it plays an important
role in the system, because it automatically wraps a Service Locator.

This Aspect is imported via our basic library Jars. It targets all
calls to methods defined on certain business interfaces, which are
marked by annotation.

The error happens when incremental compilation kicks in after changing
any class bearing the @BussFasade


Note: we use hasmethod()

Below is a shortened excerpt:

    public pointcut ServicePoint()
        : call( * (@BussFasade *).*(..) )
          && !@within(Clientside)
          && !@annotation(Clientside)
          && ( !@within(ServiceImplementation)
             || @withincode(Clientside)
             )
          ;

    declare @type
        : hasmethod(* (@BussFasade *).*(..))
        : @ServiceImplementation;

    public @interface ServiceImplementation {  }




    private pointcut call_Servermethod(Object businessTarget)
        : ServicePoint()
          && target(businessTarget);

    Object around(Object bussFasade)
        : call_Servermethod(bussFasade)
     {
	.....
     }