Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Christoph Läubrich]

No I think more about

if (severity == "WARN") {
  log.warn("There is something wrong");
} else if (severity == "ERROR") {
  throw new MojoFailureException("...") {
} else {
  throw new MojoExecutionException("...") {
}

That way the plugin can handle any error/failure/... in a way that the 
user can "downgrade" a certain problem if desired.



Am 18.03.22 um 00:06 schrieb Tibor Digana:

@Christoph
FATAL ,   WARN ,   ERROR
They are log levels?
The plugin does not control the log level after caught exception in Maven
core. The Maven Core does!
I think it's time to make a demo.

On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich 
wrote:


Hi Tibor,

it shouldn't be to hard to guess another property like

maven.test.jvmcrash=FATAL
maven.test.failure=WARN
maven.test.error=ERROR

:-)

Am 16.03.22 um 12:25 schrieb Tibor Digana:

Hi Christoph,

Such a granularity with error/failure might be also an additional
requirement but still you miss the third option to JVM error which is
different from test error/failure - they don;t have the same meaning.

T


On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich 
Just wondering but maybe it would be better to configure the severity
instead of a true/false, something like:

maven.test.failure=WARN
maven.test.error=ERROR

would only warn about failing tests but thrw exception if starting the
test fails?

Am 14.03.22 um 10:52 schrieb Tibor Digana:

Romain, it is not a bug.
Don't consider this as a bug. It was a feature request for change by
Olivier, and not a bug.
I closed both issues years ago but not because of ignorance but because

the

appearance of the exceptional behavior is a wrong compromise and which

does

not help anyone and even it makes the situation worse because typically
other group of users would fire a new Jira tickets. You would not be

able

to satisfy two contradictory parties which have completely different
opinions, and so we use to introduce new params and this way we satisfy
both parties, they may combine the params as they wish, and everybody

would

be happy and nobody would claim. Many technical solutions might exist,

e.g.

param=boolean|string or new param=boolean, whatever.

The truth is that this problem with (java --add-reads ...) happened in

our

ASF environment on Java 8 which in good configuration would not happen

and

should not.
It is not right way that we abuse "maven.test.failure.ignore" which

would

tell us "Hey, you have illegal configuration in your build system and

it

would not work by JDK design", it is not the goal of the plugin to tell

you

that you have configured the build wrong because it won't and the same
configuration of the plugin (not the build)  says "ignore the error".
Yesterday I discussed this problem with Herve and we independently

observed

equal opinions and that's not everything because we understood that the
purpose of the config parameter is to not throw MOJO exception which is
right, but the exceptional behavior should have an exact new param for

the

exact use case.
SPI for this parameter is too much because no user would implement it

for a

trivial parameter;; the SPI is used to be implemented by frameworks or
systems or application servers but this is not our case.




On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


+1
if it is to investigate a CI issue, it is generally easy to add debug
insights (by code or agent) so a SPI sounds like the sanest for the

plugin

to me.

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. 14 mars 2022 à 09:08, Guillaume Nodet  a

écrit

:


If that's not currently possible, maybe a SPI should be provided so

that

people can use plug in extensions to analyze the test result and

override

it if necessary (transforming an error into a warning, storing

results

in a

way which is easier to use by other tools later...) ?

Guillaume

Le lun. 14 mars 2022 à 07:43, Christoph Läubrich <

m...@laeubi-soft.de>

a

écrit :


I also agree that the test at least should run, we use this property

to

run the test and produce result and later on have a buildstep that
analyze the results (and probably fail the build job).

As it is not recommend, I wonder what is the recommended way to

archive

something similar?

Am 14.03.22 um 06:29 schrieb Olivier Lamy:

On Mon, 14 Mar 2022 at 11:55, Tibor Digana 


wrote:



In case of the user property *maven.test.failure.ignore* the MOJO

must

not

throw any exception which is interpreted by the Maven Core as

BUILD

SUCCESS.



This is a very simple reduction of the problem description.
The documentation here

Re: issues with the user property "maven.test.failure.ignore" and new proposals

[Tibor Digana]

@Christoph
FATAL ,   WARN ,   ERROR
They are log levels?
The plugin does not control the log level after caught exception in Maven
core. The Maven Core does!
I think it's time to make a demo.

On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich 
wrote:

> Hi Tibor,
>
> it shouldn't be to hard to guess another property like
>
> maven.test.jvmcrash=FATAL
> maven.test.failure=WARN
> maven.test.error=ERROR
>
> :-)
>
> Am 16.03.22 um 12:25 schrieb Tibor Digana:
> > Hi Christoph,
> >
> > Such a granularity with error/failure might be also an additional
> > requirement but still you miss the third option to JVM error which is
> > different from test error/failure - they don;t have the same meaning.
> >
> > T
> >
> >
> > On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich  >
> > wrote:
> >
> >> Just wondering but maybe it would be better to configure the severity
> >> instead of a true/false, something like:
> >>
> >> maven.test.failure=WARN
> >> maven.test.error=ERROR
> >>
> >> would only warn about failing tests but thrw exception if starting the
> >> test fails?
> >>
> >> Am 14.03.22 um 10:52 schrieb Tibor Digana:
> >>> Romain, it is not a bug.
> >>> Don't consider this as a bug. It was a feature request for change by
> >>> Olivier, and not a bug.
> >>> I closed both issues years ago but not because of ignorance but because
> >> the
> >>> appearance of the exceptional behavior is a wrong compromise and which
> >> does
> >>> not help anyone and even it makes the situation worse because typically
> >>> other group of users would fire a new Jira tickets. You would not be
> able
> >>> to satisfy two contradictory parties which have completely different
> >>> opinions, and so we use to introduce new params and this way we satisfy
> >>> both parties, they may combine the params as they wish, and everybody
> >> would
> >>> be happy and nobody would claim. Many technical solutions might exist,
> >> e.g.
> >>> param=boolean|string or new param=boolean, whatever.
> >>>
> >>> The truth is that this problem with (java --add-reads ...) happened in
> >> our
> >>> ASF environment on Java 8 which in good configuration would not happen
> >> and
> >>> should not.
> >>> It is not right way that we abuse "maven.test.failure.ignore" which
> would
> >>> tell us "Hey, you have illegal configuration in your build system and
> it
> >>> would not work by JDK design", it is not the goal of the plugin to tell
> >> you
> >>> that you have configured the build wrong because it won't and the same
> >>> configuration of the plugin (not the build)  says "ignore the error".
> >>> Yesterday I discussed this problem with Herve and we independently
> >> observed
> >>> equal opinions and that's not everything because we understood that the
> >>> purpose of the config parameter is to not throw MOJO exception which is
> >>> right, but the exceptional behavior should have an exact new param for
> >> the
> >>> exact use case.
> >>> SPI for this parameter is too much because no user would implement it
> >> for a
> >>> trivial parameter;; the SPI is used to be implemented by frameworks or
> >>> systems or application servers but this is not our case.
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Mar 14, 2022 at 9:11 AM Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >>> wrote:
> >>>
>  +1
>  if it is to investigate a CI issue, it is generally easy to add debug
>  insights (by code or agent) so a SPI sounds like the sanest for the
> >> plugin
>  to me.
> 
>  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. 14 mars 2022 à 09:08, Guillaume Nodet  a
> >> écrit
>  :
> 
> > If that's not currently possible, maybe a SPI should be provided so
> >> that
> > people can use plug in extensions to analyze the test result and
> >> override
> > it if necessary (transforming an error into a warning, storing
> results
>  in a
> > way which is easier to use by other tools later...) ?
> >
> > Guillaume
> >
> > Le lun. 14 mars 2022 à 07:43, Christoph Läubrich <
> m...@laeubi-soft.de>
> >> a
> > écrit :
> >
> >> I also agree that the test at least should run, we use this property
> >> to
> >> run the test and produce result and later on have a buildstep that
> >> analyze the results (and probably fail the build job).
> >>
> >> As it is not recommend, I wonder what is the recommended way to
> >> archive
> >> something similar?
> >>
> >> Am 14.03.22 um 06:29 schrieb Olivier Lamy:
> >>> On Mon, 14 Mar 2022 at 11:55, Tibor Digana  >
> >> wrote:
> >>>
>  In case of the user property 

Re: [VOTE] Release Apache Maven JXR version 3.2.0

[Hervé BOUTEMY]

+1

Reproducible Builds ok: reference was done with JDK 8 on *nix

Regards,

Hervé

Le mercredi 16 mars 2022, 22:13:14 CET Tamás Cservenák a écrit :
> +1
> 
> On Tue, Mar 15, 2022, 20:20 Slawomir Jaranowski 
> 
> wrote:
> > Hi,
> > 
> > We solved 7 issues:
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12330847
> > yleName=Text=12317527
> > 
> > There are still a couple of issues left in JIRA:
> > 
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20JXR%20AND%20res
> > olution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20D
> > ESC
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1727/
> > 
> > https://repository.apache.org/content/repositories/maven-1727/org/apache/m
> > aven/jxr/jxr/3.2.0/jxr-3.2.0-source-release.zip
> > 
> > Source release checksum(s):
> > jxr-3.2.0-source-release.zip - SHA-512 :
> > 
> > 3e543870442906307b5b11eed607bb9b1bd8f42e7ceb66474bae731698c3dfe7a3e2cedd46
> > 57ddc79c0172292f185ab0aac90811230a6122d3d285943a14097f
> > 
> > Staging site:
> > https://maven.apache.org/jxr-archives/jxr-LATEST/
> > 
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for at least 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> > 
> > --
> > Sławomir Jaranowski





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

Re: Release of maven-verifier

[Slawomir Jaranowski]

Hi

Konrad thanks for your contribution.

Every PR was merged.

List of resolved issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12351428

I'm going to release 1.8.0 at the weekend (19-20 of March)

Does anybody else want to add something more?


wt., 8 mar 2022 o 08:26 Konrad Windszus  napisał(a):

> Hi,
> I would really appreciate if some committers could look at the following
> three PRs for maven-verifier
>
> https://github.com/apache/maven-verifier/pull/4 <
> https://github.com/apache/maven-verifier/pull/4>
> https://github.com/apache/maven-verifier/pull/6 <
> https://github.com/apache/maven-verifier/pull/6>
> https://github.com/apache/maven-verifier/pull/9 <
> https://github.com/apache/maven-verifier/pull/9>
>
> Afterwards a new release would be great.
> Maybe someone can dedicate some time...
>
> Thanks in advance,
> Konrad



-- 
Sławomir Jaranowski

Re: [shade] why is pom in 3.3.1-SNAPSHOT?

[Romain Manni-Bucau]

+1 from me

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



Le jeu. 17 mars 2022 à 14:02, Slawomir Jaranowski 
a écrit :

> Hi
>
> 3.3.0 was not released,
> 3.2.4 is last one
>
> There are new features in release notes.
>
> so it look like we simpli try again release 3.3.0
>
>
> czw., 17 mar 2022 o 13:43 Romain Manni-Bucau 
> napisał(a):
>
> > Right but it got cancelled and does not have any tag so is it really a
> > partial rollback like it looks like or did I miss something and we should
> > stick to 3.3.1 for next version?
> > Asking cause I'd need somebody with the perms to close
> > https://issues.apache.org/jira/browse/MSHADE-412 but I'm not sure which
> > version to ask as fixVersion now.
> >
> > 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 jeu. 17 mars 2022 à 09:31, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > a écrit :
> >
> > > Hi
> > >
> > > https://lists.apache.org/thread/03s84xfjghj37nnjwncj0mo0ymw3z0wg
> > >
> > > czw., 17 mar 2022 o 08:57 Romain Manni-Bucau 
> > > napisał(a):
> > >
> > > > Hi all,
> > > >
> > > > Why is shade pom in 3.3.1-SNAPSHOT and not 3.3.0-SNAPSHOT or
> > > > 3.2.5-SNAPSHOT?
> > > > Did I miss some release?
> > > >
> > > > 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
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [shade] why is pom in 3.3.1-SNAPSHOT?

[Slawomir Jaranowski]

Hi

3.3.0 was not released,
3.2.4 is last one

There are new features in release notes.

so it look like we simpli try again release 3.3.0


czw., 17 mar 2022 o 13:43 Romain Manni-Bucau 
napisał(a):

> Right but it got cancelled and does not have any tag so is it really a
> partial rollback like it looks like or did I miss something and we should
> stick to 3.3.1 for next version?
> Asking cause I'd need somebody with the perms to close
> https://issues.apache.org/jira/browse/MSHADE-412 but I'm not sure which
> version to ask as fixVersion now.
>
> 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 jeu. 17 mars 2022 à 09:31, Slawomir Jaranowski 
> a écrit :
>
> > Hi
> >
> > https://lists.apache.org/thread/03s84xfjghj37nnjwncj0mo0ymw3z0wg
> >
> > czw., 17 mar 2022 o 08:57 Romain Manni-Bucau 
> > napisał(a):
> >
> > > Hi all,
> > >
> > > Why is shade pom in 3.3.1-SNAPSHOT and not 3.3.0-SNAPSHOT or
> > > 3.2.5-SNAPSHOT?
> > > Did I miss some release?
> > >
> > > 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
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>


-- 
Sławomir Jaranowski

Re: [shade] why is pom in 3.3.1-SNAPSHOT?

[Romain Manni-Bucau]

Right but it got cancelled and does not have any tag so is it really a
partial rollback like it looks like or did I miss something and we should
stick to 3.3.1 for next version?
Asking cause I'd need somebody with the perms to close
https://issues.apache.org/jira/browse/MSHADE-412 but I'm not sure which
version to ask as fixVersion now.

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



Le jeu. 17 mars 2022 à 09:31, Slawomir Jaranowski 
a écrit :

> Hi
>
> https://lists.apache.org/thread/03s84xfjghj37nnjwncj0mo0ymw3z0wg
>
> czw., 17 mar 2022 o 08:57 Romain Manni-Bucau 
> napisał(a):
>
> > Hi all,
> >
> > Why is shade pom in 3.3.1-SNAPSHOT and not 3.3.0-SNAPSHOT or
> > 3.2.5-SNAPSHOT?
> > Did I miss some release?
> >
> > 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
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven JXR version 3.2.0

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise

On 15.03.22 20:20, Slawomir Jaranowski wrote:

Hi,

We solved 7 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12330847=Text=12317527

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20JXR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1727/
https://repository.apache.org/content/repositories/maven-1727/org/apache/maven/jxr/jxr/3.2.0/jxr-3.2.0-source-release.zip

Source release checksum(s):
jxr-3.2.0-source-release.zip - SHA-512 :
3e543870442906307b5b11eed607bb9b1bd8f42e7ceb66474bae731698c3dfe7a3e2cedd4657ddc79c0172292f185ab0aac90811230a6122d3d285943a14097f

Staging site:
https://maven.apache.org/jxr-archives/jxr-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1



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

Re: [shade] why is pom in 3.3.1-SNAPSHOT?

[Slawomir Jaranowski]

Hi

https://lists.apache.org/thread/03s84xfjghj37nnjwncj0mo0ymw3z0wg

czw., 17 mar 2022 o 08:57 Romain Manni-Bucau 
napisał(a):

> Hi all,
>
> Why is shade pom in 3.3.1-SNAPSHOT and not 3.3.0-SNAPSHOT or
> 3.2.5-SNAPSHOT?
> Did I miss some release?
>
> 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
> >
>


-- 
Sławomir Jaranowski

[shade] why is pom in 3.3.1-SNAPSHOT?

[Romain Manni-Bucau]

Hi all,

Why is shade pom in 3.3.1-SNAPSHOT and not 3.3.0-SNAPSHOT or 3.2.5-SNAPSHOT?
Did I miss some release?

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

Small issue with Maven Site plugin

[Patrick Pok]

Hello Maven Site DEV Team,

First of all, I hope you this email finds you well.
I wanted to reach out, and hopefully this is not a trouble, regarding the Maven 
Site plugin.
Please also allow me to express my gratitudes towards this amazing plugin.

Background, I do some analysis with this command: mvn clean install site -U -T 
10
Everything runs, and during the execution, I am always getting this, 100 
reproducible:

[WARNING] *
[WARNING] * Your build is requesting parallel execution, but project  *
[WARNING] * contains the following plugin(s) that have goals not marked   *
[WARNING] * as @threadSafe to support parallel building.  *
[WARNING] * While this /may/ work fine, please look for plugin updates*
[WARNING] * and/or request plugins be made thread-safe.   *
[WARNING] * If reporting an issue, report it against the plugin in*
[WARNING] * question, not against maven-core  *
[WARNING] *
[WARNING] The following plugins are not marked @threadSafe in:
[WARNING] org.apache.maven.plugins:maven-site-plugin:3.11.0
[WARNING] Enable debug to see more precisely which goals are not marked 
@threadSafe.
[WARNING] *

I was wondering if Maven Site team can provide assistance on this thread safe 
warning.
Made some research, and may I ask if it is something as simple as adding an 
@threadSafe annotation somewhere in the source repo?

Anyhow, I am just thankful for the work you guys have done for this.
Wishing you a good day and a good week.

- Patrick Pok
patrick_...@icloud.com