Absolute paths in builddef.lst make the builds non reproducible

[ebourg]

aspectj-maven-plugin generates a builddef.lst file with the detailed options passed to AspectJ and this file is embedded in the final jar. The various paths appearing in this file are all absolute, which means someone else rebuilding a project using the plugin will be unable to reproduce a byte identical artifact (see https://reproducible-builds.org for why it matters).

I suggest using relative paths instead (or removing the file if it isn't important).

[ebourg]

This issue has been addressed in Debian with this patch:

https://salsa.debian.org/java-team/aspectj-maven-plugin/blob/master/debian/patches/01-relative-path-in-build-config-file.patch

[sammyhk]

@ebourg I think this project has been abandoned, please make a pull request to https://github.com/nickwongdev/aspectj-maven-plugin , we definitely need this.

[borramboy]

I have the same problem.

[kriegaex]

I just fixed this problem for the AspectJ.dev plugin variant in commit dev-aspectj/aspectj-maven-plugin@b4c9a8c. You also find comprehensive Javadoc and an example integration test there.

If you add this snapshot repository https://oss.sonatype.org/content/repositories/snapshots to your POM, you can test it without building the plugin yourself. I just deployed a snapshot there. Feedback is welcome. If it works for you, I can soon publish a release.

Please note that I did not follow @ebourg's example to replace absolute by relative paths for the following reasons:

• The Debian patch is incomplete. There are more places where replacements would be necessary.
• The replaceAll call only works for UNIX paths with forward slashes. The backslashes on Windows would cause exceptions, because they are interpreted as part of a regex. (I tried, this is not theory.) That could of course be fixed by escaping them properly, but I found a better way to address the problem, so this way of scattering lots of replaceAll calls throughtout the code base is unnecessary.
• Relative paths would not solve the reproducibility problem, because where e.g. the AspectJ runtime aspectjrt-*.jar is located in the local Maven repository relative to the project build directory, is clearly system- oder even user-dependent. So that approach simply does not cut it.

The correct solution is to not package the argument files into the build artifact in the first place by locating them outside target/classes and target/test-classes. For backward compatibility, this is not the default, but with the new option argumentFileDirectory easily doable, if you care about reproducible builds.

P.S.: In the preceding commit dev-aspectj/aspectj-maven-plugin@a323cd2, I also made the AspectJ Maven builds themselves reproducible. Part of it has also been implemented here in the MojoHaus version, but only for the main JAR, not for the Javadoc JAR. My commit solves both issues.

@ebourg I think this project has been abandoned, please make a pull request to https://github.com/nickwongdev/aspectj-maven-plugin , we definitely need this.

Correction: The project had been inactive for ~3.5 years, which is why Nick created his fork. After he had officially abandoned that one too, I created the AspectJ.dev fork, which is actively maintained and more feature-rich than this one. As an AspectJ committer, I am trying to keep it in sync with AspectJ releases, if new plugin options make sense. For new AspectJ releases or Java versions as such, you do not even need to upgrade the plugin since 1.13.1, only upgrade the AspectJ Tools plugin dependency and increase the source, target, compliance level or release option you want. My plugin does not have a fixed upper limit for Java versions, so it does not depend on a new plugin release to upgrade Java or AspectJ. The user can do it independently.

Please also note that the MojoHaus plugin is (kind of) alive again, too. At least last year there was a release 1.14.0, supporting Java 16.

[kriegaex]

FYI, AspectJ.dev AspectJ Maven Plugin 1.14 containing the fix for this problem has been released and is available on Maven Central.

[tia-ru]

It's better to make default value "${project.build.directory}" for "argumentFileDirectory" option instead of "${project.build.outputDirectory}". The "${project.build.directory}" points to "target" directory that is not included in jar artefact