Sorry for the delay! You’re right, it’s not as bad as I had first gathered from the PRs to core plugins.
Here’s a list of APIs that we use that are now causing compile errors: (1) org.apache.maven.lifecycle.internal.MojoDescriptorCreator#convert now returns org.apache.maven.internal.xml.Xpp3Dom instead of org.codehaus.plexus.util.xml.Xpp3Dom (2) org.apache.maven.settings.crypto.DefaultSettingsDecryptionRequest#DefaultSettingsDecryptionRequest(org.apache.maven.settings.Server) now expects an instance of org.apache.maven.api.settings.Server (3) org.apache.maven.settings.crypto.SettingsDecryptionRequest#getProxies and #setProxies now works with org.apache.maven.api.settings.Proxy instead of org.apache.maven.settings.Proxy We use (1) to validate to check whether certain properties are configured on other plugins. It’s obviously in an internal package so breaking it is fair game. Is there a better way of doing this or maybe even a new API? We use (2) and (3) to decrypt the servers and proxies configured in settings.xml to use them for our own HTTP client inside our extension. Is there a better way of doing this? Some APIs are now deprecated, e.g. AbstractMojo.getLog() or MavenExecutionRequest.getProxies(). Is there a plan to remove them in a 4.x version or will they be around until at least 5.x? Thanks, Marc On 4. Oct 2022 at 16:02:44, Guillaume Nodet <gno...@apache.org> wrote: > As indicated by Tamas, the merge is not supposed to break existing plugins. > Could you be more specific about the exact breaking changes ? > > Le mar. 4 oct. 2022 à 12:42, Marc Philipp <m...@gradle.com> a écrit : > > Hi everyone, > > > We’re maintaining a Maven extension and testing it against the latest > > snapshots. After the merge of https://github.com/apache/maven/pull/703 our > > tests started failing because of breaking API changes. I see there are PRs > > to core Maven plugins linked from there. If I understood it correctly, this > > change will break all/most existing Maven plugins. > > > Maven 4.0 is a major new version and as such is obviously allowed to make > > breaking changes to its API. However, I was wondering if there’s any > > guidance or a migration path for (third-party) Maven plugins and > > extensions? Is the idea that they’ll also have to publish new major > > versions that are compatible with 4.x? If they still need to support 3.x, > > would they need to maintain long-lived branches and release 3.x and 4.x > > compatible versions until they decide to drop support for 3.x? Or will > > there be any kind of compatibility layer? > > > Thanks, > > Marc > > > -- > > > Marc Philipp > > > Senior Principal Software Engineer > > > Gradle GmbH > > Firmensitz: Danckelmannstr. 21, 14059 Berlin, Germany > > > Registergericht: Amtsgericht Charlottenburg, HRB 162310 > > > Geschäftsführer: Dr. Rolf Dockter > > > P. +49 30 609886880 > > W. gradle.com > > > [image: > > > > https://dpesummit.com/?utm_source=employee-signature&utm_medium=email&utm_campaign=dpesummit > > ] > > < > > > https://dpesummit.com/?utm_source=employee-signature&utm_medium=email&utm_campaign=dpesummit > > > > > > > > -- > ------------------------ > Guillaume Nodet >
