Re: [aspectj-users] Usage question

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hi Archie,

What you are trying to do sounds reasonable. The unusual thing I do notice is that you have the inpath and destdir set the same for your final iajc call. That could introduce weirdness.  The only strict ordering policy for processing files is that aspects are processed before classes.  This can mean on different runs of the compiler the classes are processed in a different order, and that should not matter. If it does matter, as you seem to be discovering, that is a bug.  With inpath/destdir the same we may find whilst weaving a file and resolving references that on one run we resolve to something already woven, on another run we don't - so that is the first thing I'd change, weave to somewhere else. It may be leading to your type not exposed problems.

You may find the build faster if you merge those final two steps...but it isn't strictly necessary.

I presume the 'type not exposed to weaver' messages were for your types and not for JRE types?

If we could distill down a simple scenario that displayed this problem, I am happy to debug into it.

cheers,

Andy

On 12 April 2013 10:25, Archie Cobbs <archie@xxxxxxxxxxxx> wrote:

I have a question about the proper usage of the <iajc> ant task, as well as a (possible) bug report. I'm using AspectJ 1.7.1.

In my project I have a bunch of normal Java code and one custom aspect.

I also have other pre-compiled aspects supplied in 3rd party JAR files (e.g., Spring's @Transactional, etc.).

I'm doing compile-time weaving.

So the steps I have been following are:

1. Compile normal *.java code using <javac> into build/classes
   
2. Compile aspects *.aj code using <iajc> into build/classes
   
3. Apply aspects (both my own and 3rd party) using <iajc>
   

Here's the problem: <iajc> was intermittently failing to weave classes. And each time I ran the build, it would be a different set of classes.

The classes that failed to weave would have the "this affected type is not exposed to the weaver" warning emitted during weaving (step #3). The classes warned (and not woven) would change each build.

Here is how ant was being used when this problem was occurring (abbreviated for clarity):

<!-- Define iajc.classpath: where to find classes that might be seen during iajc compile -->
<path id="iajc.classpath">
    <path refid="javac.classpath"/>
    <pathelement location="build/classes"/>
</path>

<!-- Define aspect.classpath: where to find pre-compiled AOP aspects -->
<path id="aspect.classpath">
    <path refid="javac.classpath"/>
    <pathelement location="build/classes"/>
</path>

<!-- Compile custom aspects -->
<iajc srcdir="src/java"
      destDir="build/classes"
      classpathRef="iajc.classpath"
      source="1.6"
      target="1.6"
      verbose="true"
      showWeaveInfo="true"
      failonerror="true">
        <include name="**/*.aj"/>
</iajc>

<!-- Compile-time weaving -->
<iajc inpath="build/classes"
      destDir="build/classes"
      classpathRef="iajc.classpath"
      source="1.6"
      target="1.6"
      verbose="true"
      showWeaveInfo="false"
      failonerror="true"
      aspectPathRef="aspect.classpath"/>

The way that I fixed the problem was by removing build/classes from both iajc.classpath and aspect.classpath (see highlights).

The latter change was counter-intuitive because, after the "Compile custom aspects" step, I thought my custom aspect would live in build/classes and so need to be found there.

So my question is: what is the proper way to do what I'm trying to do? Must *.java/*.class and *.aj/*.class files be kept strictly separated?

And the possible bug is: why does <iajc> randomly fail to weave classes just because classpathRef and/or aspectPathRef has more stuff in it?

And even though the way I was doing it before may be improper usage, why is there non-determinism in the result? That seems bad in itself.

Thanks,
-Archie

--
Archie L. Cobbs



_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users