testacc-art/aspectj-maven-plugin

AspectJ Maven Plugin

AspectJ Maven Plugin

Overview

This plugin weaves AspectJ aspects into your classes using the AspectJ compiler ajc. Typically, aspects are used in one of two ways within your Maven reactors:

• As part of a single project, implying aspects and code are defined within the same Maven module. This is the simplest approach to start out with. Feel free to examine the "Examples: single-project AspectJ use" documentation section to better understand single-project use.

• As part of a multi-module Maven reactor, where one or more modules contain aspects and other modules within contain code using those aspects ("woven by the aspects"). This is a more complex and powerful approach, best suited when several Maven projects should be woven by a common set of aspects. The "Examples: multi-module AspectJ use" documentation section contains a basic walk-through of this approach.

Documentation

Plugin documentation for all AspectJ Maven goals and usage examples can be found here:

https://dev-aspectj.github.io/aspectj-maven-plugin/

Differences to Mojo's AspectJ Maven Plugin by MojoHaus

At the time of writing this, the MojoHaus team is preparing a new release 1.14.0, the first one in ~3.5 years. They reactivated the original project, accepting some old pull requests which were long ago contained in a fork (see History). This would have been good news before I started maintaining the project. Now the situation is, that they refused to contribute to the AspectJ.dev fork. When I tried talking about merging back my changes into their project instead, my requests for a phone conference or online chat were refused. I wanted to make sure that no changes or new features would get lost, so I started creating some pull requests and issues. Some trivial ones were accepted, some (to me) more important ones refused. In the end, I closed them, deciding to keep maintaining this project instead, because I did not want to lose any prior work by Nick Wong or myself. Please by all means feel free to use the MojoHaus version, if you feel better with it. Just don't get tripped up by their versioning, continuing with 1.14 instead of 1.13 like me, after Nick had released 1.12.1 and 1.12.6 before already, and I had released 1.13.M2 and 1.13.M3. At first, a MojoHaus team agreed with me that it was a good idea to continue with 1.13, but now I see that someone created a 1.14.0.

Feature comparison

As far as I know, the MojoHaus plugin does not have any features that this one here does not have. If there are any, it would be my own oversight not to have noticed, but I do not think that I missed anything important. The AspectJ.dev version has the following improvements compared to MojoHaus:

• It is unnecessary to always specify complianceLevel in addition to source and target, because in this plugin you can simply use either complianceLevel for identical source/target versions or source and target, if you want to use a target byte code level different from the source level. You should not use all three. In MojoHaus you have to, because if you do not specify complianceLevel, it will counter-intuitively revert to the AspectJ default of 1.4, even though you also specified source and target.
• Since AspectJ 1.9.8.M1, the --release N switch works correctly and is supported by a new parameter release in this plugin. For that purpose, version 1.13 of this plugin depends on AspectJ 1.9.8.M1, while MojoHaus 1.12.0 depends on AspectJ 1.9.7, which does not have --release N support yet. Furthermore, if release is used, it automatically takes precedence over all of complianceLevel, source, target.
• You can use Java preview features using the enablePreview option, which maps to the --enable-preview compiler option at your own risk. The documentation explains the consequences and limitations, because many Java users are unaware of them. I chose to rather add a separate option and document it well than to force users to use the new additionalCompilerArgs switch, not fully knowing what they are doing.
• Even though JMS (Java Module System) support is still sketchy, I decided to offer an option javaModules in order to enable users to at least have a simple way to put Maven dependencies on the module path via the --module-path compiler option. Robert Scholte suggested a better way to implement JMS support in AspectJ Maven, similar to how Maven Compiler does it, but I am not confident I can implement it correctly. He did not volunteer to do it either, so for now this new option is better than nothing.
• The documentation for this plugin is somewhat better than the MojoHaus version, if you look at the Maven site, e.g. the additional UML diagram for the multi-module example and some improved configuration parameter descriptions for the compile and
• test-compile goals. The same help texts for all Maven goals of course are also available from the command line, e.g. via mvn dev.aspectj:aspectj-maven-plugin:help -Ddetail=true -Dgoal=compile. This is of course true for all Maven plugins, I am just mentioning it for your convenience.
• This plugin is prepared to recognise Java 17 for complianceLevel, source and target, while MojoHaus 1.12.0 supports a maximum version of 16. In combination with using a development version of AspectJ in your build, you can already compile Java 17 code and create Java 17 class files. As soon as Java 17 is final and the Eclipse Java compiler fully supports it, I am also going to release a new final AspectJ version, which then of course you can also use with this plugin by simply upgrading the AspectJ dependency. A plugin update will not be necessary. See here for an example Maven POM using a Java-17-enabled AspectJ snapshot version.

History

This plugin was formerly provided by Codehaus, then migrated to Mojohaus where it was no longer maintained after version 1.11.

Because Java 9+ support was missing, Nicholas Wong (nickwongdev) forked and published it under group ID com.nickwongdev. He did this until early 2020 and version 1.12.6 containing Java 13 support. Then he announced he would no longer be available to maintain the plugin and recommended forking it again.

Presently, Alexander Kriegisch (kriegaex) has taken responsibility and upgraded the plugin to support Java 14-17 and AspectJ version 1.9.7, which he co-developed in collaboration with maintainer Andy Clement. Future plugin releases will have the group ID dev.aspectj, hoping to give the plugin a permanent home, whoever might maintain it in the future.