Community
Participate
Working Groups
Can't get the iajc task to work with my source code structure (see below). I tried a simple replacement of javac task to iajc task and it does not work. Have been trying with other configurations with the iajc task without look. I am probably doing something wrong, but it has come to my attention that iajc should work as a drop-in replacement for javac. code structure under src directory: example/server/... example/agent/... example/common/... example/logging/... example/[other packages] Note: only the source code under example/server is to be compiled, but the source code under example/server uses code from both example/logging and example/common. I have compile-server target that basically compiles the source code under example/server/... With javac I did: <javac debug="${compiler.debug}" source="${compiler.source}" target="${compiler.target}" destdir="${build.dir}/classes" srcdir="src"> <classpath refid="compile.server.classpath" /> <include name="example/server/**" /> </javac> replacing "javac" with "iajc" causes the build to fail (see attachment ant.log for details) with several "cannot be resolved". Most (all?) of the failing resolves are when refering to common and logging.
Created attachment 42690 [details] Ant build output uploaded ant.log with the Ant build output showing all the errors from the build
I'm not suggesting this as a fix - but its a possible workaround for you. In the documentation for the compiler adapter we ship: http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-adapter.html it shows how to continue using the javac task and just have it delegate to the ajc compiler once it has worked out the set of files to compile. As it describes - just make sure aspectjtools.jar is in the ant/lib folder, then invoke ant specifying the build.compiler property ant -Dbuild.compiler=org.aspectj.tools.ant.taskdefs.Ajc11CompilerAdapter ...
Another guy in our team got it to work with the following workaround: <iajc debug="${compiler.debug}" source="${compiler.source}" target="${compiler.target}" destdir="${build.dir}/classes" srcdir="src"> <classpath refid="compile.server.classpath" /> <include name="example/common/**" /> <include name="example/server/**" /> <include name="example/logging/**" /> </iajc> His comment was: "Changed compile-server target to use only source code, which was needed to get it to work. Should be possible to use .class-files, but the documentation is not entirely clear what the difference is when using the iajc ant task." SO, the actually issue remains. IAJC is not a drop-in replacement for javac
The difference lies in javac searching the sourcepath. It would probably be more correct to update the javac task to put the logging and common binaries on the classpath when building. i.e., Your current javac task finds the sources for logging and commons by searching under src, but you seem to imply that these are built in a separate step. So a correct javac task would have the logging and commons binaries on the classpath after building them. It may be harmless to re-seek them under src/ because there is no change between the time they are compiled and the time javac re-uses the source for the later compile, but in fact you're not compiling against the binaries you're shipping (Sorry, I forget: does javac recompile logging and commons if using them to resolve types?). The AspectJ compiler doesn't do what javac does (resolving using sourcepath), so if that's exactly what you want, then yes, iajc is not a drop-in replacement. However, iajc can be a drop-in replacement for any java compile if the javac task is set up to permit that, by e.g., not relying on sourcepath seeks. Your workaround works for iajc, but it is not what you wanted for javac, so switching involves a build file change or switch. The better workaround is to put logging and commons binaries on the classpath when compiling server. Then you can use the same compile specification for both javac and iajc, switching using the javac.compiler property (if I'm remembering the property name correctly). iajc acts as a drop-in replacement for javac only when not relying on features of the javac compiler not supported in AspectJ. I believe that there are no compilations that *require* such features (i.e., they can always be specified otherwise), so iajc can compile anything javac does, albeit requiring a compatible compile specification. I'm inclined to close this as-designed, but update the docs accordingly. Thanks for the well-stated bug and please let us know if you disagree.
We just migrated our enviroment from Ant to Maven, so be my guest :) No seriously, I don't have a problem you closing this as with "as-designed". But, like you wrote, it would be helpful if the documentation was updated accordingly. The "drop-in replacement" was the reason that I got stuck - "this works under javac, so it should work with iajc"..
Fixed/documented in antsupport.xml,1.22
