Please show support / vote for toolchain support in java action

[Christoph Läubrich]

Github Actions become very popular to build maven projects, but 
currently misses a convenience way to setup the java versions.


There is currently on-going work to better support this:

https://github.com/actions/setup-java/issues/276

it would be great if you could leave a comment (or even review the PR) 
and vote for the issue so it becomes more attraction.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

On Mon, Jul 11, 2022 at 10:42 AM Tamás Cservenák  wrote:
>
> Howdy,
>
> seems m-site-p 3.11.0 introduced something that broke Maven2 (!!) jdepend
> plugin (comes from parent).
>
> I could make it work like this
> mvn clean package org.apache.maven.plugins:maven-site-plugin:3.10.0:site
> -DskipTests

That command breaks in a different way for me:

WARNING] An issue has occurred with apache-rat-plugin:0.14:rat report,
skipping LinkageError
org.apache.rat.mp.RatReportMojo.generate(Lorg/codehaus/doxia/sink/Sink;Ljava/util/Locale;)V,
please report an issue to Maven dev team.
java.lang.AbstractMethodError:
org.apache.rat.mp.RatReportMojo.generate(Lorg/codehaus/doxia/sink/Sink;Ljava/util/Locale;)V
at 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)

So,Catch-22 :-(

Using:

Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 1.8.0_322, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac"

On Java 11, it also fails like this:

[WARNING] An issue has occurred with apache-rat-plugin:0.14:rat
report, skipping LinkageError Receiver class
org.apache.rat.mp.RatReportMojo does not define or inherit an
implementation of the resolved method 'abstract void
generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface
org.apache.maven.reporting.MavenReport., please report an issue to
Maven dev team.
java.lang.AbstractMethodError: Receiver class
org.apache.rat.mp.RatReportMojo does not define or inherit an
implementation of the resolved method 'abstract void
generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface
org.apache.maven.reporting.MavenReport.
at 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute

Re: MojoExecutionException and MojoFailureException

[Benjamin Marwell]

Here you go.

https://issues.apache.org/jira/browse/MSHARED-1032




On Mon, 11 Jul 2022, 20:21 Benjamin Marwell,  wrote:

>
> Please note there are more exceptions, e.g. in reporting. That's always
> been a problem. Not sure, but I must have opened an issue for this
> somewhere.
>
> Just for the sake of completeness.
>
>
> On Mon, 11 Jul 2022, 14:12 Guillaume Nodet,  wrote:
>
>> Yes, that's why I only kept a single exception in the new API.
>>
>> Le lun. 11 juil. 2022 à 13:59, Romain Manni-Bucau 
>> a
>> écrit :
>>
>> > It got aligned AFAIK ->
>> >
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau  |  Blog
>> >  | Old Blog
>> >  | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn  | Book
>> > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> >
>> >
>> > Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich 
>> a
>> > écrit :
>> >
>> > > I might be wrong, but in case of "build FAILURE" only a short error is
>> > > printed saying user should enable -X while with "BUILD ERROR" the
>> > > exception is printed, maybe with a hint not to blame maven :-)
>> > >
>> > > Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
>> > > > Hi,
>> > > >
>> > > > In all discussions about this topic it seems that this distinctions
>> > never
>> > > > had been useful so there seems to be an agreement to get a single
>> > > exception
>> > > > "something went wrong in the mojo".
>> > > > Guess at the end being finer grain is not that useful for end user
>> and
>> > > > makes writing mojo harder but I agree it can be neat to wrap the
>> error
>> > > in a
>> > > > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and
>> add
>> > the
>> > > > source of the error...but at the end for end user it is the same, it
>> > > failed
>> > > > so he must read why and fix it so not sure it is worth the effort.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau  |  Blog
>> > > >  | Old Blog
>> > > >  | Github <
>> > > https://github.com/rmannibucau> |
>> > > > LinkedIn  | Book
>> > > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > > >
>> > > >
>> > > > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák 
>> a
>> > > > écrit :
>> > > >
>> > > >> Howdy,
>> > > >> and along this line...
>> > > >>
>> > > >> BUILD FAILURE - uncompilable source, test failed, badly configured
>> > > plugin,
>> > > >> missing something from build, etc. all the issues that user CAN
>> (and
>> > > >> should) fix to have build pass, usually by editing sources, POM or
>> > > >> settings.
>> > > >>
>> > > >> BUILD ERROR - disk full, no perm to write to disk (ie. during
>> > resolve),
>> > > >> remote repo unreachable (during resolve), etc. issues  user MAY fix
>> > (ie.
>> > > >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
>> > > >>
>> > > >> T
>> > > >>
>> > > >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák <
>> ta...@cservenak.net
>> > >
>> > > >> wrote:
>> > > >>
>> > > >>> Howdy,
>> > > >>>
>> > > >>> AFAIR one of the reasons for these two exceptions were to
>> distinguish
>> > > >>> cases like:
>> > > >>> * expected exception during execution of Mojo: most typical,
>> > > uncompilable
>> > > >>> source, or bad config/param, or something alike, condition the
>> user
>> > CAN
>> > > >>> (and should) fix, usually by editing sources, POM or settings.
>> > > >>> * unexpected exception during execution of Mojo: IO/permission,
>> disk
>> > > >> full,
>> > > >>> network, whatever -- this condition user MAY fix or may not be
>> able
>> > to
>> > > >> fix
>> > > >>> (ie. some remote resource is down)
>> > > >>>
>> > > >>> Re Guillaume proposal: IMHO it lacks this distinction above
>> > > >>>
>> > > >>> T
>> > > >>>
>> > > >>>
>> > > >>> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet > >
>> > > >> wrote:
>> > > >>>
>> > >  I have the following proposal for the new API:
>> > > 
>> > > 
>> > > 
>> > > >>
>> > >
>> >
>> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
>> > > 
>> > >  Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
>> > > >> s.jaranow...@gmail.com
>> > > >
>> > >  a écrit :
>> > > 
>> > > > Hi
>> > > >
>> > > > Today - Maven 3.8.6 both exception generate the same message:
>> BUILD
>> > >  FAILURE
>> > > >
>> > > > We have some inconsistencies in javadocs descriptions [1].
>> > > > We also have the wrong description on guide page [2].
>> > > >
>> > > > There was a 

Re: MojoExecutionException and MojoFailureException

[Benjamin Marwell]

Please note there are more exceptions, e.g. in reporting. That's always
been a problem. Not sure, but I must have opened an issue for this
somewhere.

Just for the sake of completeness.


On Mon, 11 Jul 2022, 14:12 Guillaume Nodet,  wrote:

> Yes, that's why I only kept a single exception in the new API.
>
> Le lun. 11 juil. 2022 à 13:59, Romain Manni-Bucau 
> a
> écrit :
>
> > It got aligned AFAIK ->
> >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich 
> a
> > écrit :
> >
> > > I might be wrong, but in case of "build FAILURE" only a short error is
> > > printed saying user should enable -X while with "BUILD ERROR" the
> > > exception is printed, maybe with a hint not to blame maven :-)
> > >
> > > Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
> > > > Hi,
> > > >
> > > > In all discussions about this topic it seems that this distinctions
> > never
> > > > had been useful so there seems to be an agreement to get a single
> > > exception
> > > > "something went wrong in the mojo".
> > > > Guess at the end being finer grain is not that useful for end user
> and
> > > > makes writing mojo harder but I agree it can be neat to wrap the
> error
> > > in a
> > > > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add
> > the
> > > > source of the error...but at the end for end user it is the same, it
> > > failed
> > > > so he must read why and fix it so not sure it is worth the effort.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák 
> a
> > > > écrit :
> > > >
> > > >> Howdy,
> > > >> and along this line...
> > > >>
> > > >> BUILD FAILURE - uncompilable source, test failed, badly configured
> > > plugin,
> > > >> missing something from build, etc. all the issues that user CAN (and
> > > >> should) fix to have build pass, usually by editing sources, POM or
> > > >> settings.
> > > >>
> > > >> BUILD ERROR - disk full, no perm to write to disk (ie. during
> > resolve),
> > > >> remote repo unreachable (during resolve), etc. issues  user MAY fix
> > (ie.
> > > >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
> > > >>
> > > >> T
> > > >>
> > > >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák <
> ta...@cservenak.net
> > >
> > > >> wrote:
> > > >>
> > > >>> Howdy,
> > > >>>
> > > >>> AFAIR one of the reasons for these two exceptions were to
> distinguish
> > > >>> cases like:
> > > >>> * expected exception during execution of Mojo: most typical,
> > > uncompilable
> > > >>> source, or bad config/param, or something alike, condition the user
> > CAN
> > > >>> (and should) fix, usually by editing sources, POM or settings.
> > > >>> * unexpected exception during execution of Mojo: IO/permission,
> disk
> > > >> full,
> > > >>> network, whatever -- this condition user MAY fix or may not be able
> > to
> > > >> fix
> > > >>> (ie. some remote resource is down)
> > > >>>
> > > >>> Re Guillaume proposal: IMHO it lacks this distinction above
> > > >>>
> > > >>> T
> > > >>>
> > > >>>
> > > >>> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 
> > > >> wrote:
> > > >>>
> > >  I have the following proposal for the new API:
> > > 
> > > 
> > > 
> > > >>
> > >
> >
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
> > > 
> > >  Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
> > > >> s.jaranow...@gmail.com
> > > >
> > >  a écrit :
> > > 
> > > > Hi
> > > >
> > > > Today - Maven 3.8.6 both exception generate the same message:
> BUILD
> > >  FAILURE
> > > >
> > > > We have some inconsistencies in javadocs descriptions [1].
> > > > We also have the wrong description on guide page [2].
> > > >
> > > > There was a discussion about it, some on slack, some on GitHub
> [3]
> > > and
> > > > connected issue MNG-7351 [4]
> > > >
> > > > As I remember we want one exception for Mojo in Maven 4.
> > > >
> > > > So it will be good to make a decision about it and fix mentioned
> > > place
> > > 

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Tamás Cservenák]

Howdy,

seems m-site-p 3.11.0 introduced something that broke Maven2 (!!) jdepend
plugin (comes from parent).

I could make it work like this
mvn clean package org.apache.maven.plugins:maven-site-plugin:3.10.0:site
-DskipTests

(package was needed as then japicmp would fail)

HTH
T


On Mon, Jul 11, 2022 at 3:52 PM Gary Gregory  wrote:

> Hi All,
>
> I'm looking for help in how to remedy an AbstractMethodError at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
>
> Running:
>
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> cd commons-dbcp
> maven clean site -DskipTests
>
> Any thoughts?
>
> [INFO] Generating "JDepend" report   ---
> jdepend-maven-plugin:2.0:generate-no-fork
> [WARNING] An issue has occurred with
> jdepend-maven-plugin:2.0:generate-no-fork report, skipping
> LinkageError null, please report an issue to Maven dev team.
> java.lang.AbstractMethodError
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:235)
> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> (DefaultSiteRenderer.java:348)
> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:194)
> at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:143)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
>
> TY,
> Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Tomo Suzuki]

My Maven (3.6.3 + Java 11) also hit the same error from the command, but
gave a better explanation:

[INFO] Generating "JDepend" report   ---
jdepend-maven-plugin:2.0:generate-no-fork
[WARNING] An issue has occurred with
jdepend-maven-plugin:2.0:generate-no-fork report, skipping LinkageError
Receiver class org.codehaus.mojo.jdepend.JDependNoForkMojo does not define
or inherit an implementation of the resolved method '*abstract void
generate(org.apache.maven.doxia.sink.Sink, java.util.Locale)*' of interface
org.apache.maven.reporting.MavenReport., please report an issue to Maven
dev team.
java.lang.AbstractMethodError: Receiver class
org.codehaus.mojo.jdepend.JDependNoForkMojo does not define or inherit an
implementation of the resolved method 'abstract void
generate(org.apache.maven.doxia.sink.Sink, java.util.Locale)' of interface
org.apache.maven.reporting.MavenReport.
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute
(SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)



(I hope the error message above will help you find a good compatible
dependency versions)


On Mon, Jul 11, 2022 at 9:52 AM Gary Gregory  wrote:

> Hi All,
>
> I'm looking for help in how to remedy an AbstractMethodError at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
>
> Running:
>
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> cd commons-dbcp
> maven clean site -DskipTests
>
> Any thoughts?
>
> [INFO] Generating "JDepend" report   ---
> jdepend-maven-plugin:2.0:generate-no-fork
> [WARNING] An issue has occurred with
> jdepend-maven-plugin:2.0:generate-no-fork report, skipping
> LinkageError null, please report an issue to Maven dev team.
> java.lang.AbstractMethodError
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:235)
> at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> (DefaultSiteRenderer.java:348)
> at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> (SiteMojo.java:194)
> at org.apache.maven.plugins.site.render.SiteMojo.execute
> (SiteMojo.java:143)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at 

maven-war-plugin packagingExcludes not working

[Jean Pierre URKENS]

Dear all,



I am trying to exclude the resources under ‘src/main/resource/db/*’ from
being included in my war file any possible configuration of the
‘packagingExcludes ‘ config parameter seems to be ignored:



My plugin-configuration as reported during the run with debug option is:

[DEBUG]
---

[DEBUG] Goal:  org.apache.maven.plugins:maven-war-plugin:3.3.2:war
(default-war)

[DEBUG] Style: Regular

[DEBUG] Configuration: 



  




true





  6.0.0-SNAPSHOT

  ${buildNumber}

  11/07/2022
13:34:24



  

  

  

  

  

  

  

  

  

  

  

  <*packagingExcludes>WEB-INF/classes/db/**/*.sql*

  

  

  

  

  

  ${maven.war.skip}

  

  

  

  op

  

  

  



 src/main/config

  

log4j.properties

  

  WEB-INF/classes



  

  

  





I also tried specifying:

   *WEB-INF/classes/db*

*WEB-INF/classes/db**/



But the generated war always includes the content of this folder. So how do
I prevent a resource folder to be included in the generated war file.

AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

Hi All,

I'm looking for help in how to remedy an AbstractMethodError at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

Running:

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
cd commons-dbcp
maven clean site -DskipTests

Any thoughts?

[INFO] Generating "JDepend" report   ---
jdepend-maven-plugin:2.0:generate-no-fork
[WARNING] An issue has occurred with
jdepend-maven-plugin:2.0:generate-no-fork report, skipping
LinkageError null, please report an issue to Maven dev team.
java.lang.AbstractMethodError
at 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)

TY,
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MojoExecutionException and MojoFailureException

[Guillaume Nodet]

Yes, that's why I only kept a single exception in the new API.

Le lun. 11 juil. 2022 à 13:59, Romain Manni-Bucau  a
écrit :

> It got aligned AFAIK ->
>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich  a
> écrit :
>
> > I might be wrong, but in case of "build FAILURE" only a short error is
> > printed saying user should enable -X while with "BUILD ERROR" the
> > exception is printed, maybe with a hint not to blame maven :-)
> >
> > Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
> > > Hi,
> > >
> > > In all discussions about this topic it seems that this distinctions
> never
> > > had been useful so there seems to be an agreement to get a single
> > exception
> > > "something went wrong in the mojo".
> > > Guess at the end being finer grain is not that useful for end user and
> > > makes writing mojo harder but I agree it can be neat to wrap the error
> > in a
> > > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add
> the
> > > source of the error...but at the end for end user it is the same, it
> > failed
> > > so he must read why and fix it so not sure it is worth the effort.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák  a
> > > écrit :
> > >
> > >> Howdy,
> > >> and along this line...
> > >>
> > >> BUILD FAILURE - uncompilable source, test failed, badly configured
> > plugin,
> > >> missing something from build, etc. all the issues that user CAN (and
> > >> should) fix to have build pass, usually by editing sources, POM or
> > >> settings.
> > >>
> > >> BUILD ERROR - disk full, no perm to write to disk (ie. during
> resolve),
> > >> remote repo unreachable (during resolve), etc. issues  user MAY fix
> (ie.
> > >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
> > >>
> > >> T
> > >>
> > >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák  >
> > >> wrote:
> > >>
> > >>> Howdy,
> > >>>
> > >>> AFAIR one of the reasons for these two exceptions were to distinguish
> > >>> cases like:
> > >>> * expected exception during execution of Mojo: most typical,
> > uncompilable
> > >>> source, or bad config/param, or something alike, condition the user
> CAN
> > >>> (and should) fix, usually by editing sources, POM or settings.
> > >>> * unexpected exception during execution of Mojo: IO/permission, disk
> > >> full,
> > >>> network, whatever -- this condition user MAY fix or may not be able
> to
> > >> fix
> > >>> (ie. some remote resource is down)
> > >>>
> > >>> Re Guillaume proposal: IMHO it lacks this distinction above
> > >>>
> > >>> T
> > >>>
> > >>>
> > >>> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 
> > >> wrote:
> > >>>
> >  I have the following proposal for the new API:
> > 
> > 
> > 
> > >>
> >
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
> > 
> >  Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
> > >> s.jaranow...@gmail.com
> > >
> >  a écrit :
> > 
> > > Hi
> > >
> > > Today - Maven 3.8.6 both exception generate the same message: BUILD
> >  FAILURE
> > >
> > > We have some inconsistencies in javadocs descriptions [1].
> > > We also have the wrong description on guide page [2].
> > >
> > > There was a discussion about it, some on slack, some on GitHub [3]
> > and
> > > connected issue MNG-7351 [4]
> > >
> > > As I remember we want one exception for Mojo in Maven 4.
> > >
> > > So it will be good to make a decision about it and fix mentioned
> > place
> >  to
> > > be consistent.
> > >
> > >
> > > [1]
> > >
> > >
> > 
> > >>
> >
> https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--
> > > [2]
> > >
> > 
> > >>
> >
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> > > [3] https://github.com/apache/maven/pull/632
> > > [4] https://issues.apache.org/jira/browse/MNG-7351
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> > 
> > 
> >  --
> >  

Re: MojoExecutionException and MojoFailureException

[Romain Manni-Bucau]

It got aligned AFAIK ->
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich  a
écrit :

> I might be wrong, but in case of "build FAILURE" only a short error is
> printed saying user should enable -X while with "BUILD ERROR" the
> exception is printed, maybe with a hint not to blame maven :-)
>
> Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
> > Hi,
> >
> > In all discussions about this topic it seems that this distinctions never
> > had been useful so there seems to be an agreement to get a single
> exception
> > "something went wrong in the mojo".
> > Guess at the end being finer grain is not that useful for end user and
> > makes writing mojo harder but I agree it can be neat to wrap the error
> in a
> > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add the
> > source of the error...but at the end for end user it is the same, it
> failed
> > so he must read why and fix it so not sure it is worth the effort.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák  a
> > écrit :
> >
> >> Howdy,
> >> and along this line...
> >>
> >> BUILD FAILURE - uncompilable source, test failed, badly configured
> plugin,
> >> missing something from build, etc. all the issues that user CAN (and
> >> should) fix to have build pass, usually by editing sources, POM or
> >> settings.
> >>
> >> BUILD ERROR - disk full, no perm to write to disk (ie. during resolve),
> >> remote repo unreachable (during resolve), etc. issues  user MAY fix (ie.
> >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
> >>
> >> T
> >>
> >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák 
> >> wrote:
> >>
> >>> Howdy,
> >>>
> >>> AFAIR one of the reasons for these two exceptions were to distinguish
> >>> cases like:
> >>> * expected exception during execution of Mojo: most typical,
> uncompilable
> >>> source, or bad config/param, or something alike, condition the user CAN
> >>> (and should) fix, usually by editing sources, POM or settings.
> >>> * unexpected exception during execution of Mojo: IO/permission, disk
> >> full,
> >>> network, whatever -- this condition user MAY fix or may not be able to
> >> fix
> >>> (ie. some remote resource is down)
> >>>
> >>> Re Guillaume proposal: IMHO it lacks this distinction above
> >>>
> >>> T
> >>>
> >>>
> >>> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 
> >> wrote:
> >>>
>  I have the following proposal for the new API:
> 
> 
> 
> >>
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
> 
>  Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
> >> s.jaranow...@gmail.com
> >
>  a écrit :
> 
> > Hi
> >
> > Today - Maven 3.8.6 both exception generate the same message: BUILD
>  FAILURE
> >
> > We have some inconsistencies in javadocs descriptions [1].
> > We also have the wrong description on guide page [2].
> >
> > There was a discussion about it, some on slack, some on GitHub [3]
> and
> > connected issue MNG-7351 [4]
> >
> > As I remember we want one exception for Mojo in Maven 4.
> >
> > So it will be good to make a decision about it and fix mentioned
> place
>  to
> > be consistent.
> >
> >
> > [1]
> >
> >
> 
> >>
> https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--
> > [2]
> >
> 
> >>
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> > [3] https://github.com/apache/maven/pull/632
> > [4] https://issues.apache.org/jira/browse/MNG-7351
> >
> > --
> > Sławomir Jaranowski
> >
> 
> 
>  --
>  
>  Guillaume Nodet
> 
> >>>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MojoExecutionException and MojoFailureException

[Christoph Läubrich]

I might be wrong, but in case of "build FAILURE" only a short error is 
printed saying user should enable -X while with "BUILD ERROR" the 
exception is printed, maybe with a hint not to blame maven :-)


Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:

Hi,

In all discussions about this topic it seems that this distinctions never
had been useful so there seems to be an agreement to get a single exception
"something went wrong in the mojo".
Guess at the end being finer grain is not that useful for end user and
makes writing mojo harder but I agree it can be neat to wrap the error in a
MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add the
source of the error...but at the end for end user it is the same, it failed
so he must read why and fix it so not sure it is worth the effort.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák  a
écrit :


Howdy,
and along this line...

BUILD FAILURE - uncompilable source, test failed, badly configured plugin,
missing something from build, etc. all the issues that user CAN (and
should) fix to have build pass, usually by editing sources, POM or
settings.

BUILD ERROR - disk full, no perm to write to disk (ie. during resolve),
remote repo unreachable (during resolve), etc. issues  user MAY fix (ie.
wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)

T

On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák 
wrote:


Howdy,

AFAIR one of the reasons for these two exceptions were to distinguish
cases like:
* expected exception during execution of Mojo: most typical, uncompilable
source, or bad config/param, or something alike, condition the user CAN
(and should) fix, usually by editing sources, POM or settings.
* unexpected exception during execution of Mojo: IO/permission, disk

full,

network, whatever -- this condition user MAY fix or may not be able to

fix

(ie. some remote resource is down)

Re Guillaume proposal: IMHO it lacks this distinction above

T


On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 

wrote:



I have the following proposal for the new API:




https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin


Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <

s.jaranow...@gmail.com



a écrit :


Hi

Today - Maven 3.8.6 both exception generate the same message: BUILD

FAILURE


We have some inconsistencies in javadocs descriptions [1].
We also have the wrong description on guide page [2].

There was a discussion about it, some on slack, some on GitHub [3] and
connected issue MNG-7351 [4]

As I remember we want one exception for Mojo in Maven 4.

So it will be good to make a decision about it and fix mentioned place

to

be consistent.


[1]





https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--

[2]




https://maven.apache.org/guides/plugin/guide-java-plugin-development.html

[3] https://github.com/apache/maven/pull/632
[4] https://issues.apache.org/jira/browse/MNG-7351

--
Sławomir Jaranowski




--

Guillaume Nodet









-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MojoExecutionException and MojoFailureException

[Romain Manni-Bucau]

Hi,

In all discussions about this topic it seems that this distinctions never
had been useful so there seems to be an agreement to get a single exception
"something went wrong in the mojo".
Guess at the end being finer grain is not that useful for end user and
makes writing mojo harder but I agree it can be neat to wrap the error in a
MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add the
source of the error...but at the end for end user it is the same, it failed
so he must read why and fix it so not sure it is worth the effort.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák  a
écrit :

> Howdy,
> and along this line...
>
> BUILD FAILURE - uncompilable source, test failed, badly configured plugin,
> missing something from build, etc. all the issues that user CAN (and
> should) fix to have build pass, usually by editing sources, POM or
> settings.
>
> BUILD ERROR - disk full, no perm to write to disk (ie. during resolve),
> remote repo unreachable (during resolve), etc. issues  user MAY fix (ie.
> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
>
> T
>
> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > AFAIR one of the reasons for these two exceptions were to distinguish
> > cases like:
> > * expected exception during execution of Mojo: most typical, uncompilable
> > source, or bad config/param, or something alike, condition the user CAN
> > (and should) fix, usually by editing sources, POM or settings.
> > * unexpected exception during execution of Mojo: IO/permission, disk
> full,
> > network, whatever -- this condition user MAY fix or may not be able to
> fix
> > (ie. some remote resource is down)
> >
> > Re Guillaume proposal: IMHO it lacks this distinction above
> >
> > T
> >
> >
> > On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 
> wrote:
> >
> >> I have the following proposal for the new API:
> >>
> >>
> >>
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
> >>
> >> Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
> s.jaranow...@gmail.com
> >> >
> >> a écrit :
> >>
> >> > Hi
> >> >
> >> > Today - Maven 3.8.6 both exception generate the same message: BUILD
> >> FAILURE
> >> >
> >> > We have some inconsistencies in javadocs descriptions [1].
> >> > We also have the wrong description on guide page [2].
> >> >
> >> > There was a discussion about it, some on slack, some on GitHub [3] and
> >> > connected issue MNG-7351 [4]
> >> >
> >> > As I remember we want one exception for Mojo in Maven 4.
> >> >
> >> > So it will be good to make a decision about it and fix mentioned place
> >> to
> >> > be consistent.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> >>
> https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--
> >> > [2]
> >> >
> >>
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> >> > [3] https://github.com/apache/maven/pull/632
> >> > [4] https://issues.apache.org/jira/browse/MNG-7351
> >> >
> >> > --
> >> > Sławomir Jaranowski
> >> >
> >>
> >>
> >> --
> >> 
> >> Guillaume Nodet
> >>
> >
>

Re: MojoExecutionException and MojoFailureException

[Tamás Cservenák]

Howdy,
and along this line...

BUILD FAILURE - uncompilable source, test failed, badly configured plugin,
missing something from build, etc. all the issues that user CAN (and
should) fix to have build pass, usually by editing sources, POM or settings.

BUILD ERROR - disk full, no perm to write to disk (ie. during resolve),
remote repo unreachable (during resolve), etc. issues  user MAY fix (ie.
wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)

T

On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák 
wrote:

> Howdy,
>
> AFAIR one of the reasons for these two exceptions were to distinguish
> cases like:
> * expected exception during execution of Mojo: most typical, uncompilable
> source, or bad config/param, or something alike, condition the user CAN
> (and should) fix, usually by editing sources, POM or settings.
> * unexpected exception during execution of Mojo: IO/permission, disk full,
> network, whatever -- this condition user MAY fix or may not be able to fix
> (ie. some remote resource is down)
>
> Re Guillaume proposal: IMHO it lacks this distinction above
>
> T
>
>
> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet  wrote:
>
>> I have the following proposal for the new API:
>>
>>
>> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
>>
>> Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski > >
>> a écrit :
>>
>> > Hi
>> >
>> > Today - Maven 3.8.6 both exception generate the same message: BUILD
>> FAILURE
>> >
>> > We have some inconsistencies in javadocs descriptions [1].
>> > We also have the wrong description on guide page [2].
>> >
>> > There was a discussion about it, some on slack, some on GitHub [3] and
>> > connected issue MNG-7351 [4]
>> >
>> > As I remember we want one exception for Mojo in Maven 4.
>> >
>> > So it will be good to make a decision about it and fix mentioned place
>> to
>> > be consistent.
>> >
>> >
>> > [1]
>> >
>> >
>> https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--
>> > [2]
>> >
>> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
>> > [3] https://github.com/apache/maven/pull/632
>> > [4] https://issues.apache.org/jira/browse/MNG-7351
>> >
>> > --
>> > Sławomir Jaranowski
>> >
>>
>>
>> --
>> 
>> Guillaume Nodet
>>
>

Re: MojoExecutionException and MojoFailureException

[Tamás Cservenák]

Howdy,

AFAIR one of the reasons for these two exceptions were to distinguish cases
like:
* expected exception during execution of Mojo: most typical, uncompilable
source, or bad config/param, or something alike, condition the user CAN
(and should) fix, usually by editing sources, POM or settings.
* unexpected exception during execution of Mojo: IO/permission, disk full,
network, whatever -- this condition user MAY fix or may not be able to fix
(ie. some remote resource is down)

Re Guillaume proposal: IMHO it lacks this distinction above

T


On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet  wrote:

> I have the following proposal for the new API:
>
>
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
>
> Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski 
> a écrit :
>
> > Hi
> >
> > Today - Maven 3.8.6 both exception generate the same message: BUILD
> FAILURE
> >
> > We have some inconsistencies in javadocs descriptions [1].
> > We also have the wrong description on guide page [2].
> >
> > There was a discussion about it, some on slack, some on GitHub [3] and
> > connected issue MNG-7351 [4]
> >
> > As I remember we want one exception for Mojo in Maven 4.
> >
> > So it will be good to make a decision about it and fix mentioned place to
> > be consistent.
> >
> >
> > [1]
> >
> >
> https://maven.apache.org/ref/3.8.6/apidocs/org/apache/maven/plugin/Mojo.html#execute--
> > [2]
> >
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> > [3] https://github.com/apache/maven/pull/632
> > [4] https://issues.apache.org/jira/browse/MNG-7351
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> 
> Guillaume Nodet
>