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 <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> Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák <ta...@cservenak.net> 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 <gno...@apache.org> > 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 > >> > > >
