You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2022/03/28 08:19:34 UTC
Surprises on maven 4
Hi all,
For an output check (thanks again Michael for the pointer), I tested maven
master/4 this morning and get a few question marks:
1. I know we warn when a plugin has no lock version but it also means we
implicitly force to define a plugin and warn we defined it, this does not
make much sense from an user point of view for me so either we should keep
a default version aligned on maven version or just not enforce any plugin
if not defined in the pom (means if I did not define install plugin, mvn
install wouldn't install - don't think it is good but it is not worse than
warning for an implicit definition when something implicit had been done
IMHO)
2. I was not able to reproduce it after an install but I got at first build
this error (mvn clean install -DskipTests -T8):
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project xxxxxxxx: Execution default-install of goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR] while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error
[ERROR] -> [Help 1]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project orchestrator: Execution default-install of
goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR] while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error
I'm a bit suspicious about this last one since there is a new resolution of
project modules, anyone with some idea?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Surprises on maven 4
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 29 mars 2022 à 09:40, Maarten Mulders <mt...@apache.org> a
écrit :
> Hi,
>
> Let me only chime in on your first question, as I have no idea about the
> latter one...
>
> On 28/03/2022 10:19, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > For an output check (thanks again Michael for the pointer), I tested
> maven
> > master/4 this morning and get a few question marks:
> >
> > 1. I know we warn when a plugin has no lock version but it also means we
> > implicitly force to define a plugin and warn we defined it, this does not
> > make much sense from an user point of view for me so either we should
> keep
> > a default version aligned on maven version or just not enforce any plugin
> > if not defined in the pom (means if I did not define install plugin, mvn
> > install wouldn't install - don't think it is good but it is not worse
> than
> > warning for an implicit definition when something implicit had been done
> > IMHO)
>
> As far as I know, we warn when a user did not explicitly lock the
> version of plugin that they inherit through the Maven Super POM. When
> the user locks that version using pluginManagement, the warning is gone.
>
> So yes, Maven still defines a default version for e.g. the resources or
> the compiler plugin, but it explains to the user: relying on this makes
> your build less stable, and this is how you can improve.
>
> I think that makes sense: it makes the build more deterministic, as it
> is no longer dependent on the version of Maven that a user has. I'm not
> sure what exactly doesn't make sense in this setup?
>
If you do something implicit then you should do something implicit or not
do it right?
So if you binding implicitly some plugins your must not emit any warning or
it means you are not sure about what you do.
I certainly understand the rational (the fear it breaks with some later
maven version for ex) but this is something we have a full control and we
can guarantee to stay backward compatible for supported maven versions.
Concretely, no default should lead to any warning and maven being
"convention over configuration", conventions should work which implies we
should:
1. only provide warning-free lifecycles
2. probably enforce a default encoding (UTF-8?)
If I need to define a ton of plugins to get rid of the warnings (to get
started warning free I need 6-7 plugins???), it can be saner to drop
lifecycles from maven and move to extensions now we have them, this way the
entry cost is a single extension (jar-extension for ex) which is a bit
better than the current user experience but still weirdish as experience
IMHO.
For any user, default bindings are part of maven-core (even if it is not in
terms of project/module but it is since we depend on it) so not having it
integrated OOTB (warnings) is negative IMHO so something we should clean up
before 4.0.0.
I'm not sure the solution is to get back to previous behavior for built-in
lifecycles or to move to something like extensions but not working properly
OOTB breaks maven design IMHO. It was already hurting for the encoding in
v2/v3 but if it becomes the same for plugins the entrycost will keep
increasing and I hope it does not go that path.
>
> > 2. I was not able to reproduce it after an install but I got at first
> build
> > this error (mvn clean install -DskipTests -T8):
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> > (default-install) on project xxxxxxxx: Execution default-install of goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
> > Unable to provision, see the following errors:
> > [ERROR]
> > [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> > [ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
> > org.eclipse.sisu.wire.WireModule ->
> > org.eclipse.sisu.plexus.PlexusBindingModule ->
> > org.apache.maven.session.scope.internal.SessionScopeModule)
> > [ERROR] while locating org.apache.maven.execution.MavenSession
> > [ERROR]
> > [ERROR] 1 error
> > [ERROR] -> [Help 1]
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> > (default-install) on project orchestrator: Execution default-install of
> > goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> failed:
> > Unable to provision, see the following errors:
> > [ERROR]
> > [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> > [ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
> > org.eclipse.sisu.wire.WireModule ->
> > org.eclipse.sisu.plexus.PlexusBindingModule ->
> > org.apache.maven.session.scope.internal.SessionScopeModule)
> > [ERROR] while locating org.apache.maven.execution.MavenSession
> > [ERROR]
> > [ERROR] 1 error
> >
> > I'm a bit suspicious about this last one since there is a new resolution
> of
> > project modules, anyone with some idea?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
>
> Thanks,
>
>
> Maarten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Surprises on maven 4
Posted by Maarten Mulders <mt...@apache.org>.
Hi,
Let me only chime in on your first question, as I have no idea about the
latter one...
On 28/03/2022 10:19, Romain Manni-Bucau wrote:
> Hi all,
>
> For an output check (thanks again Michael for the pointer), I tested maven
> master/4 this morning and get a few question marks:
>
> 1. I know we warn when a plugin has no lock version but it also means we
> implicitly force to define a plugin and warn we defined it, this does not
> make much sense from an user point of view for me so either we should keep
> a default version aligned on maven version or just not enforce any plugin
> if not defined in the pom (means if I did not define install plugin, mvn
> install wouldn't install - don't think it is good but it is not worse than
> warning for an implicit definition when something implicit had been done
> IMHO)
As far as I know, we warn when a user did not explicitly lock the
version of plugin that they inherit through the Maven Super POM. When
the user locks that version using pluginManagement, the warning is gone.
So yes, Maven still defines a default version for e.g. the resources or
the compiler plugin, but it explains to the user: relying on this makes
your build less stable, and this is how you can improve.
I think that makes sense: it makes the build more deterministic, as it
is no longer dependent on the version of Maven that a user has. I'm not
sure what exactly doesn't make sense in this setup?
> 2. I was not able to reproduce it after an install but I got at first build
> this error (mvn clean install -DskipTests -T8):
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project xxxxxxxx: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
> Unable to provision, see the following errors:
> [ERROR]
> [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> [ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> [ERROR] while locating org.apache.maven.execution.MavenSession
> [ERROR]
> [ERROR] 1 error
> [ERROR] -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project orchestrator: Execution default-install of
> goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
> Unable to provision, see the following errors:
> [ERROR]
> [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> [ERROR] at ClassRealm[plexus.core, parent: null] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule ->
> org.apache.maven.session.scope.internal.SessionScopeModule)
> [ERROR] while locating org.apache.maven.execution.MavenSession
> [ERROR]
> [ERROR] 1 error
>
> I'm a bit suspicious about this last one since there is a new resolution of
> project modules, anyone with some idea?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
Thanks,
Maarten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org