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
