Le mar. 29 mars 2022 à 09:40, Maarten Mulders <mthmuld...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >