Thanks for restoring compatibility! Saves us from having to use reflection to be compatible with 3.x and 4.x.
Cheers, Marc On 8. Oct 2022 at 08:57:27, Tamás Cservenák <ta...@cservenak.net> wrote: > 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 > > >
