You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Marc Philipp <ma...@gradle.com> on 2022/10/04 10:42:35 UTC
Maven 4.0: Migration path for plugins and extensions?
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>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
no, Maven does not use it currently and the reason is simple: Maven had no
API so far (no surface *meant* to be API, to be more precise).
Every non-trivial plugin/extension had to go to maven-core (like THE
implementation) to get hold onto things.
The only real API (meaning: meant as such, meant as API) was the
maven-plugin-api, but that one is enough only to
define Mojos, but in a moment you want to interact with Maven, you have to
reach to maven-core (its internals).
We are adding JApiCmp to resolver [1], and will most probably add it to the
new Maven4 API as well.
[1] https://github.com/apache/maven-resolver/pull/183
Thanks
T
On Tue, Oct 4, 2022 at 1:51 PM Gary Gregory <ga...@gmail.com> wrote:
> Does Maven and it's own plugins use JApiCmp or any tool to detect binary
> compatibility breaks?
>
> Gary
>
> On Tue, Oct 4, 2022, 06:53 Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Howdy,
> >
> > It should not break, but if it does, we did something wrong.
> >
> > The new API will coexist with old stuff, so in essence Maven 3 plugins
> > should not break with Maven 4, as long Maven 4 provides this "backward
> 3.x
> > compat window"
> > (but no Maven2 compat anymore, we cannot provide two major versions
> > spanning compat layer).
> > For how long it is undecided yet (4.1? 4.5? etc).
> >
> > Can you share more details about your breakage so we can fix things up?
> >
> >
> > Thanks
> > Tamas
> >
> >
> > On Tue, Oct 4, 2022 at 12:42 PM Marc Philipp <ma...@gradle.com> wrote:
> >
> > > 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
> > > >
> > >
> >
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Gary Gregory <ga...@gmail.com>.
Does Maven and it's own plugins use JApiCmp or any tool to detect binary
compatibility breaks?
Gary
On Tue, Oct 4, 2022, 06:53 Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> It should not break, but if it does, we did something wrong.
>
> The new API will coexist with old stuff, so in essence Maven 3 plugins
> should not break with Maven 4, as long Maven 4 provides this "backward 3.x
> compat window"
> (but no Maven2 compat anymore, we cannot provide two major versions
> spanning compat layer).
> For how long it is undecided yet (4.1? 4.5? etc).
>
> Can you share more details about your breakage so we can fix things up?
>
>
> Thanks
> Tamas
>
>
> On Tue, Oct 4, 2022 at 12:42 PM Marc Philipp <ma...@gradle.com> wrote:
>
> > 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
> > >
> >
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
It should not break, but if it does, we did something wrong.
The new API will coexist with old stuff, so in essence Maven 3 plugins
should not break with Maven 4, as long Maven 4 provides this "backward 3.x
compat window"
(but no Maven2 compat anymore, we cannot provide two major versions
spanning compat layer).
For how long it is undecided yet (4.1? 4.5? etc).
Can you share more details about your breakage so we can fix things up?
Thanks
Tamas
On Tue, Oct 4, 2022 at 12:42 PM Marc Philipp <ma...@gradle.com> wrote:
> 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
> >
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Marc Philipp <ma...@gradle.com>.
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 <gn...@apache.org> wrote:
>
> Le ven. 7 oct. 2022 à 17:57, Marc Philipp <ma...@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 <gn...@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 <ma...@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
>
>
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <gn...@apache.org> wrote:
> Le ven. 7 oct. 2022 à 17:57, Marc Philipp <ma...@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 <gn...@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 <ma...@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
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 7 oct. 2022 à 17:57, Marc Philipp <ma...@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 <gn...@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 <ma...@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
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Marc Philipp <ma...@gradle.com>.
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 <gn...@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 <ma...@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
>
Re: Maven 4.0: Migration path for plugins and extensions?
Posted by Guillaume Nodet <gn...@apache.org>.
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 <ma...@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