A rewrite of GMaven, a Maven plugin for Groovy
[#280] The 3.0.1 jar was corrupt (thanks @eugene-sadovsky for reporting this!).
None.
The CVE fixed were related to dependencies of the plugin. While I haven't done an analysis of whether they were exploitable (since this is a Maven plugin and not an application), it seems unlikely.
skipBytecodeCheck causes the Groovy version to be reported as not supporting the goal (thanks for reporting this @jgenoctr!).None.
The CVEs fixed were related to dependencies of the plugin. While I haven't done an analysis of whether they were exploitable (since this is a Maven plugin and not an application), it seems unlikely.
Maven's compatibility plan marked Maven versions older than 3.2.5 as EOL in March 2023. Therefore, we now require 3.2.5 to move forward with the rest of the ecosystem.
Fixing the validation warnings removed some Maven dependencies from the plugin's classpath (instead of using the ones from Maven itself). I'm not aware of any negative consequences of this, but it's possible certain specialized use cases might encounter changes in behavior.
None.
NullPointerExceptions that were causing confusion and instead throwing our own exception).bindPropertiesToSeparateVariables is false. The error logging when this happens has been improved.5, 6, 7, 8, and 1.9 arguments to targetBytecode so that validation doesn't unexpectedly fail since it uses the maven.compiler.target property and these arguments are valid for javac.This release requires Java 8 and drops support for Java 7. This was necessary to update dependencies which fix vulnerabilities. Specifically, in maven-archiver. At the time of release, the following dependencies were not compatible with Java 7
This is not the first breaking release, but it is the first breaking release to follow the semver conventions.
None.
The Jansi upgrade should generally be compatible, but could cause issues with scripts that were using Jansi 1.x specific classes.
None.
PROJECT_ONLY classpath. Thanks for reporting this @TobiX!None
This should be a non-breaking change (except for unusual situations that were relying on the previous incorrect behavior). However, since it's a significant change, I'm bumping the version by more than just the patch version.
This potentially runs slower than before, since a new classloader is instantiated each execution, rather than resuing the same classloader, so the classes referenced will have to be reinitialized.