Howdy, just one remark: as I said, Maven so far never had a "surface" meant to be an API, on the other hand Maven tries its best to "signal" internal areas. In this very example org.apache.maven.lifecycle.internal.MojoDescriptorCreator the package name is "internal" (sometimes impl, etc). The intent here was to be clear that this package is for internal use (implementation detail), and should not be externally used. Or, if the developer still decides to use it, he should be very clear about the consequences.
Package names like "internal", "impl" should be avoided in general. If someone cannot solve some use cases without using internal stuff, please ping us, so we can add support for that use case as well to new M4 API, as depending on internal/impl stuff of Maven just leads to inevitable breakage. Thanks T On Fri, Oct 7, 2022 at 9:52 PM Guillaume Nodet <gno...@apache.org> wrote: > Le ven. 7 oct. 2022 à 17:57, Marc Philipp <m...@gradle.com> a écrit : > > > Sorry for the delay! You’re right, it’s not as bad as I had first > gathered > > from the PRs to core plugins. > > > > Yes, switching to the new API involves a bit more, that's for sure ! > > > > > > 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 > > > > Passing from the v4 api to the v3 is usually easy. All the v3 api objects > now wrap v4 immutable objects, so there's usually a constructor that takes > a v4 object, and a getDelegate() method to access the underlying v4 object. > org.apache.maven.api.settings.Proxy proxyv4 = ...; > org.apache.maven.settings.Proxy proxyv3 = new > org.apache.maven.settings.Proxy( proxyv4 ); > and > org.apache.maven.settings.Proxy proxyv3 = ...; > org.apache.maven.api.settings.Proxy proxyv4 = proxyv4.getDelegate(); > > > > 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? > > > > For the MojoDescriptorCreator, it's mostly untouched and still heavily > based on the v3 api, so it makes sense to revert that single change. The > PluginDescriptor is currently not covered by the v4 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? > > > > I think a service SettingsDecrypter service may be needed in the v4 api so > that we can keep the old one compatible for some time. > > > > > > 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? > > > > There's an unfinished discussion around the log api for plugins. > Currently, the v4 api has a Log component that can be injected into v4 > plugins. > > The general idea is to try to be as much compatible until the v4 api can be > settled, at which point, we'd want to deprecate all the v3 code and then > get rid of it. > Nothing is currently set in stone, so we'd be happy to have feedback on the > API to make it evolve to cover more use cases. > > Guillaume > > > > 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 > > > > > > > > -- > ------------------------ > Guillaume Nodet >
