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

[Tibor Digaňa]

Christoph, just let me briefly explain the log level hierarchy.
If you select WARN log level, then ERROR can be printed too.
Similar with INFO, means that WARN and ERROR would be printed as well.

The real decision making in the plugin is a bit more complicated, see the
pull request https://github.com/apache/maven-surefire/pull/478
After I have replied to this email, I would verify the behavior of the
plugin simulating OOM.


T


On Fri, Mar 18, 2022 at 5:42 AM Christoph Läubrich 
wrote:

> 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 <
> m...@laeubi-soft.de
> >>>
> >>> 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
> 

Race condition in slf4j-simple

[Tibor Digaňa]

Hi Ceki,

We have observed a strange behavior of the logger slf4j-simple when two or
more parallel Maven modules log the exceptions and the messages.

It produces corrupted lines in the log and they are partially mixed with
other lines.
The lines look like this and they are obviously not expected in the log.

[ERROR] R] *.util.json.formatter.JsonFormatterTest
 [ERROR] Process Exit Code: 0
[ERROR] *.util.json.formatter.JsonFormatterTest


After our analysis we found the place in SLF4J code which seems to be the
root cause.

The method [1] is a critical section and must be synchronized with a
singleton lock which avoids reordering of the nested method calls across
multiple Threads. Without it, the normal messages and stack trace may mix
especially if two parallel Maven modules print the stacktrace.

[1]:
https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243

Pls analyse the class SimpleLogger.java and answer with your opinion about
this issue and a proposal with the fix.
If there are more other critical sections which need to have some
concurrency treatments, we can talk about it in this mailing list.

-- 
Cheers
Tibor

Re: Supporting building with incompatible JDK versions on a single project

[Tibor Digaňa]

The example given by Guillaume looks interesting.

  jre-options =
${jre-${java.specification.version}-options:-${jre-default-options}}
  jre-default-options = [default options]
  jre-1.8 = [my JDK 1.8 specific options]

But I would maybe distinguish between:
1. Maven options
2. and plugin options

And to be more specific, the first case (1) may have more alternatives with
[root]/.mvn/jvm.config.
Example:
1. [root]/.mvn/jvm9.config
2. [root]/.mvn/jvm11.config
3. [root]/.mvn/jvm16.config

It does not make sense to have "--add-opens" and similar things in the
jvm.config for plugins (2) because the lifecycle and plugins are complex.
We should not end up with a kind of config structure in the jvm.config. Due
to this we have POM structure.

Perhaps the POM should have new non/transitive entry points dedicated for
the phases of the build life cycle rather than parameters (entry points) in
the plugins.
I believe the users would be lucky if e.g. JUnit5 BOM (one for compile,
runtime, another for test and test-compile) would have these entry points
(as a recommendation from the OSS groups) and the user would just use it
without writing "--add-reads ... --add-exports ... --add-opens ...
--add-modules ... etc.".


Cheers
Tibor


On Wed, Jun 16, 2021 at 2:27 PM Guillaume Nodet  wrote:

> Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau  a
> écrit :
>
> > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet  a
> écrit
> > :
> >
> > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet  a
> > > écrit
> > > > :
> > > >
> > > > > A few plugins that fail with the same problem found by googling a
> > bit:
> > > > >  https://youtrack.jetbrains.com/issue/IDEA-266556
> > > > >  https://github.com/projectlombok/lombok/issues/2681
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16
> > > > > That's just the first page on google... so I don't think this is me
> > > > running
> > > > > into a corner case.  JDK 16 has only been release 2 months ago, and
> > the
> > > > > rules have changed quite a bit since JDK 15, so that's not an old
> > > > problem,
> > > > > it's a new one.
> > > > >
> > > >
> > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in -
> > > > understand we can't have the correct jpms options by default since
> > we'll
> > > > never know all plugins.
> > > >
> > > > Maybe I'm the only one, but when I see a project with a pom.xml and I
> > > just
> > > want to build it, the first thing I try is `mvn install -DskipTests`.
> > This
> > > work in most of the case, and I think it should stay that way. That's
> why
> > > I'm looking for a way to configure those options per-project.
> > >
> > > So yes, that's right, MAVEN_OPTS may solve the problem.  But that does
> > not
> > > solve my problem which is:
> > >   * how to set up the environment (maven options or jvm options or
> > > eventually environment variable)
> > >   * with a config per project (not at the maven installation level)
> > >   * with something that can have a bit of logic so that it can depend
> on
> > > which jdk version is used
> > >
> >
> > setenv.sh in multimoduleroot/.mvn ;)
> >
> >
> Actually, thinking about it, this also raises a few problems.  It makes the
> life for tools embedding maven much more complicated.
> I'm wondering if a configuration based solution wouldn't be easier to work
> with (i.e. without having to interpret or spawn a command shell) ?
>
> In felix / karaf, the problem was solved by using property files and
> property substitution.  This could look like:
>   jre-options =
> ${jre-${java.specification.version}-options:-${jre-default-options}}
>   jre-default-options = [default options]
>   jre-1.8 = [my JDK 1.8 specific options]
>
> This kind of configuration allows you to lay out a bit of logic in the
> configuration.
> This is just an example of course, but it would be more inlined with the
> [root]/.mvn/jvm.config and like.
>
> Guillaume
>
>
> > >
> > >
> > >
> > > >
> > > > >
> > > > > I think adding the --illegal-access=permit option on the command is
> > > > > sufficient to solve all those problems, but the problem is still
> the
> > > > same :
> > > > > this option will break if using JDK 1.8.  This has to be configured
> > on
> > > > the
> > > > > project and not globally.
> > > > >
> > > >
> > > > This will likely break soon so I wouldn't consider it as an option.
> > > >
> > >
> > > See above, I'm not looking for maven to fix the problem.  I'm looking
> for
> > > maven to provide a way to fix the problem.  Which implies, the exact
> > option
> > > to configure is up to the user, so the fact that is already deprecated
> is
> > > irrelevant.
> > >
> > > >
> > > >
> > > > >
> > > > > I'm not sure 

Re: [VOTE] Release Maven Resolver version 1.6.3

[Tibor Digaňa]

+1


On Tue, May 4, 2021 at 3:32 PM Michael Osipov  wrote:

> Hi,
>
> we solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12350071
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Resolver
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1644/
>
> https://repository.apache.org/content/repositories/maven-1644/org/apache/maven/resolver/maven-resolver/1.6.3/maven-resolver-1.6.3-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.6.3-source-release.zip
>
> 01830e805aa80bc5cc286b014a4b36a42af8e9414820e800a940d687bbe14a4a9f80b29f50f504e67a7c3ff295ac6ac2146c881d1136364fe77a4223627779f7
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
>
> +1
>
> But same issue as on the 5.0.x branch...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Cheers
Tibor

Re: Failing IT's on Linux in GitHub Actions

[Tibor Digaňa]

yes, there was one more issue with host.
I also had to turn "localhost" to 127.0.0.1 in the socket.
T

On Sun, Apr 18, 2021 at 11:48 PM Olivier Lamy  wrote:

> Hi,
> Do not change ports or use hard coded ports.
> The current ITs are using port 0 which means Jetty will allocate a
> random available port.
> There must be some problems with host lookup. In some environments (such as
> kubernetes) using localhost or 127.0.0.1 can be problematic.
> What is the error?
>
> What is the status of using java8 for IT tests? (current ITs are using a
> very very old version of Jetty 9.0.4...)
>
>
> On Mon, 19 Apr 2021 at 06:56, Tibor Digana  wrote:
>
> > I had exactly the same problem and I added one more step to the CI which
> > checked all open ports.
> > For instance they changed something in Github and 8081 or 8082 was
> > allocated.
> > There was a conflict with the ports and I had to shift mine, that;s it.
> >
> > T
> >
> > On Sun, Apr 18, 2021 at 8:17 PM Maarten Mulders 
> > wrote:
> >
> > > Hi all,
> > >
> > > It seems the following IT's predictably fail on Linux (not on Windows
> or
> > > MacOS) in GitHub Actions, but not at all in Jenkins:
> > >
> > > * MavenIT0146InstallerSnapshotNaming
> > > * MavenITmng2387InactiveProxyTest
> > > * MavenITmng4991NonProxyHostsTest
> > >
> > > This is also the case in master, by the way. What they have in common
> is
> > > that they all spin up an HTTP server during the test, but apparently
> > > that server cannot be reached under all circumstances.
> > >
> > > Does anyone have an idea what might be causing this and how we could
> > > address this?
> > >
> > > Thanks,
> > >
> > > Maarten
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>


-- 
Cheers
Tibor

Re: [DISCUSS] configuration for Reproducible Builds

[Tibor Digaňa]

Let's not talk about technologies but talk about the use case because the
use case will uncover the purpose what target is in the background of this
request.
Romain, an therefore i was not firstly talking about concret SCM, but
Harald, and it means the SCM can be one of the implementations -
strategies. Then we will be closer to incremental build...

The problem is that "buildTimeStamp" means one purpose for you and
something else for other e.g. build-helper:timestamp-property.
Therefore it's better to list all usecases and we will see if we really
need build timestamp or another type of timestamp and what about
guarantees. Or this solution is only a glue code between POM and the User?
Just a question. The usecase would uncover all practicies with this
property, even if it is realistic and reliable.

T

On Sun, Sep 29, 2019 at 8:07 PM Romain Manni-Bucau 
wrote:

> scm does not work cause one common use case is to rebuild from source the
> same artifacts (debian rebuild from source AFAIK, even java apps)
> since scm can be "proxied", copied etc then the source can differ and
> therefore commits can be differents but the content can be the same
> this is why jib uses epoch+1s to enforce reproducibility.
> that said once you have the timestamp the code is the same so let's not
> block on that, worse case we would enable to plug a value resolver with a
> few default strategy.
> this is not the central part of the feature IMHO.
>
> 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 dim. 29 sept. 2019 à 19:58, Tibor Digana  a
> écrit :
>
> > yes Hunter, exactly this was one possibility.
> > The names of the property can be just like in the HTTP Headers:
> > Last-Modified
> > If-Modified-Since -> maybe here can be also the commit hash, not only
> time
> > in millis/UTC
> > ETag
> >
> > and every module may have different value ;-) then. and then the SCM...
> has
> > to resolve " If-Modified-Since " to the TIME.
> > The missing "..." is some layer useful in the incremental build too.
> >
>


-- 
Cheers
Tibor

Re: [maven-jenkins-lib] branch master updated: [INFRA-18734] Jenkins builds fail on email notifications due to unknown user ID "github"

[Tibor Digaňa]

Try now!
Should be fine.

On Fri, Aug 2, 2019 at 9:10 PM Robert Scholte  wrote:

> There's a problem with this commit, see
> https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/github-19/1/console
> [
> https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/github-19/1/console
> ]
>
> java.util.NoSuchElementException: Cannot access last() element from an
> empty List
> On 2-8-2019 17:11:06, tibordig...@apache.org 
> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> tibordigana pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/maven-jenkins-lib.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 1d7b4bc [INFRA-18734] Jenkins builds fail on email notifications due
> to unknown user ID "github"
> 1d7b4bc is described below
>
> commit 1d7b4bc7dc060e412f3bd0d238802fc01ef8937e
> Author: tibordigana
> AuthorDate: Fri Aug 2 17:09:58 2019 +0200
>
> [INFRA-18734] Jenkins builds fail on email notifications due to unknown
> user ID "github"
> ---
> vars/asfMavenTlpPlgnBuild.groovy | 5 -
> vars/asfMavenTlpStdBuild.groovy | 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/vars/asfMavenTlpPlgnBuild.groovy
> b/vars/asfMavenTlpPlgnBuild.groovy
> index ae610ef..a3e9007 100644
> --- a/vars/asfMavenTlpPlgnBuild.groovy
> +++ b/vars/asfMavenTlpPlgnBuild.groovy
> @@ -99,7 +99,10 @@ def call(Map params = [:]) {
> echo "* FAST FAILURE *\n\nFast failure triggered by
> ${taskContext.failingFast}\n\n* FAST FAILURE *"
> }
> stage("Notifications") {
> - jenkinsNotify()
> + def isFirstBuild = currentBuild == null || currentBuild.changeSets ==
> null
> + def authors = isFirstBuild ? [] :
> currentBuild.changeSets.last().toList().collect { it.author.toString()
> }.unique()
> + println("The author of the last change: ${authors}")
> + if (isFirstBuild || !authors.contains('github')) jenkinsNotify()
> }
> }
> }
> diff --git a/vars/asfMavenTlpStdBuild.groovy
> b/vars/asfMavenTlpStdBuild.groovy
> index b0d1d0d..d906adf 100644
> --- a/vars/asfMavenTlpStdBuild.groovy
> +++ b/vars/asfMavenTlpStdBuild.groovy
> @@ -179,7 +179,10 @@ def call(Map params = [:]) {
> echo "* FAST FAILURE *\n\nFast failure triggered by
> ${failingFast}\n\n* FAST FAILURE *"
> }
> stage("Notifications") {
> - jenkinsNotify()
> + def isFirstBuild = currentBuild == null || currentBuild.changeSets ==
> null
> + def authors = isFirstBuild ? [] :
> currentBuild.changeSets.last().toList().collect { it.author.toString()
> }.unique()
> + println("The author of the last change: ${authors}")
> + if (isFirstBuild || !authors.contains('github')) jenkinsNotify()
> }
> }
> }
>
>

-- 
Cheers
Tibor

Re: ASF slack vs gitter.im

[Tibor Digaňa]

+1, and then well propagate our Maven Gitter via *badges* in
Maven-GitHub/README.md, *maven.apache.org * links,
*Stackoverflow*, etc.

On Sun, Mar 24, 2019 at 9:04 AM Enrico Olivelli  wrote:

> Hi guys,
> I have recently discovered gitter.im whch is open to the public and well
> integrated with github.
>
> We started using Slack but the channel we have is only for Apache
> committers.
>
> Does anyone ever thought about using gitter for Mavrn community?
>
> Enrico
>


-- 
Cheers
Tibor