Upgrade or add plugin for AspectJ 1.1

I'm using Aspect 1.1 for many things and I'll update the plugin for the rc1 release.

This is to send some thoughts on how to set up better build rules than the current plugin – not that you asked or need advice, but I thought that if you're working on it, it might help to review at least one approach before you get started. Mind you, I'd be happy if you just replicate the behavior in the initial plugin, and I'm sorry I can't render this as a jelly script patch.

Bytecode weaving and binary aspects make it easier to layer in aspects and to use aspects from another projects. A set of build rules could be:

0 javac/.java compiles happen as usual

1 use AspectJ to compile aspectsrc/ directory
or .aj files in src/ directory into
{product}-aspects.jar. If aspects are unchanged,
this need not be recompiled.

2 do 1 unless ${aspect-config-file}; if so, build
{product}-aspectj.jar using
-argfile ${aspect-config-file

3 if ${use-aspects-default} is true, then
by default weave any available {product}-aspects.jar
with the initial {product}.jar (produced by javac)
to create a final {product}.jar (urk: names)

4 if ${aspectpath} is defined, then use that to weave
final, notwithstanding rule 3 not being triggered.

5 perhaps support a separate default for testsrc?

6 if a project has required production aspects
(i.e., all the code must always be compiled with
aspectj), then either the code can all be put in
aspectsrc and the jar names fixed up or the
build.compiler property can be set to use
AspectJ or use a flag ${requires.aspectj} or
use a goal. (read: i dunno)

7 (unfortunately) if the aspects change, then the
base system also might need to be recompiled.
This is beyond the standard dependency checking.

These rules/controls should cover the standard use cases:

• aspects acting as compile-time checks
  (e.g., of architectural constraints)

• test-only (optional or required), but only for testsrc

• optional debugging or profiling aspects
  in production code

• required aspects in the production system

• any of the above using aspects from another (common) project

This approach minimizes the use of the AspectJ compiler. I think most users will be relieved to continue using their Java compiler where possible. It helps that if their aspects don't change, the only cost is the bytecode weaving step at the end, but it hurts that if they do change, any potentially-affected code should be rewoven if not recompiled.

Thanks for listening. I'll be here Wed a.m. (pacific) if you have questions.

Here is the updated aspectj plugin that i'm using for a while.

Working on it as we speak... Not sure it'll be ready for 1.0rc1 though. Will try my best.

fyi, as of today aspectj 1.1.1 is a hair's breadth from releasing. The most relevant update is that resources in -injar entries are now automatically copied to the -outjar or -d destDir. The release candidate is at

http://download.eclipse.org/technology/ajdt/aspectj-1.1.1rc1.jar.

ok. Thanks Wes. I've just committed the first version of the new 2.0 aspectj plugin!

I can always update it to 1.1.1 if it is released before maven rc1 release.

I have a few questions:

• the Xnoweave attribute seems not to work (it says it is ignoring it but I don't know if I've used it correctly: I wrote: X="noweave").
• is it really not possible to weave on class files rather than on jar? That would help. I'm currently weaving on jar but some plugins (like the war one) use class files directly without going through the jar step

Could you have a quick review of the plugin and tell me if it matches what you were expecting?

Thanks
-Vincent

Thanks for doing that! It's really great to hear. Some replies:

Sorry, I haven't had time to boot maven and check it out. I might have time before Thursday.

1.1.1 was released today.

Sorry, -Xnoweave is special-cased: use `Xnoweave="true"` (That said, I strongly recommend never using that option. It's unsupported (-X) and known to have bugs.)

It would be more convenient to weave from a directory of .class files, but (a) we haven't implemented it yet, mostly because (b) it raises questions of what to do if a .class file changes. Supporting only zip archives helps enforce the requirement to collect together all the binary input to be considered.

I suppose we could have an Ant task should support an option `-Xindir {dir}`. It would create a zip for the contents of {dir}, delete the contents, and add {dir} to the -injars list. In the case of compiler errors, it would have to restore the contents of the directory. Like -copyInjars, this might migrate back to the compiler once used.

This really isn't an issue for 1.0.

What do we do? Close it? Set up a separate jira project for the plugin?

We're now using AspectJ 1.2rc1 which allows bytecode weaving into directories.