[GitHub] [maven-jlink-plugin] dependabot[bot] opened a new pull request #41: Bump plexus-java from 1.0.6 to 1.0.7
dependabot[bot] opened a new pull request #41: URL: https://github.com/apache/maven-jlink-plugin/pull/41 Bumps [plexus-java](https://github.com/codehaus-plexus/plexus-languages) from 1.0.6 to 1.0.7. Commits https://github.com/codehaus-plexus/plexus-languages/commit/1b9a66590acc07f59f0ab4124162c69ddc8f56ad";>1b9a665 [maven-release-plugin] prepare release plexus-languages-1.0.7 https://github.com/codehaus-plexus/plexus-languages/commit/781600e5e7d9c22bbf0701fe04f4e5f114fb62e7";>781600e [maven-release-plugin] rollback the release of plexus-languages-1.0.7 https://github.com/codehaus-plexus/plexus-languages/commit/22b6e96aaf6995aef0901dc35ffec41f6b3681fc";>22b6e96 [maven-release-plugin] prepare release plexus-languages-1.0.7 https://github.com/codehaus-plexus/plexus-languages/commit/d317fa13b8bcfa223ffdb6ee3f7984c01fbf6b0e";>d317fa1 Bump release-drafter/release-drafter from v5.13.0 to v5.15.0 https://github.com/codehaus-plexus/plexus-languages/commit/83921e48375b14f5798e292a7b65053a807ab8f2";>83921e4 Bump actions/cache from v2.1.3 to v2.1.4 https://github.com/codehaus-plexus/plexus-languages/commit/40f57c77923db5259485097988ca0538e844aa03";>40f57c7 Bump junit from 4.13.1 to 4.13.2 https://github.com/codehaus-plexus/plexus-languages/commit/fbe59511ace6372b09cd34ca465d92bf69fa4edb";>fbe5951 https://github-redirect.dependabot.com/codehaus-plexus/plexus-languages/issues/70";>#70 Jars of which modulename extraction cause an exception should end up on t... https://github.com/codehaus-plexus/plexus-languages/commit/249f8bd6c55afdc281ed5c3185b20c3859e86b24";>249f8bd https://github-redirect.dependabot.com/codehaus-plexus/plexus-languages/issues/64";>#64 BinaryModuleInfoParser.parse does not take toolchain into account https://github.com/codehaus-plexus/plexus-languages/commit/a1b61e06394026b123517e57d89d7ecd0e9db939";>a1b61e0 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-languages/compare/plexus-languages-1.0.6...plexus-languages-1.0.7";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #100: Bump maven-bundle-plugin from 3.5.1 to 5.1.2
dependabot[bot] opened a new pull request #100: URL: https://github.com/apache/maven-indexer/pull/100 Bumps maven-bundle-plugin from 3.5.1 to 5.1.2. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs
[ https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310264#comment-17310264 ] Romain Manni-Bucau commented on MSHADE-385: --- Hi [~mkarg], seems your statement is not accurate and we actually support mjar release as expected. Here is a quick sample project which shows it: [https://gist.github.com/rmannibucau/bee0fff499fdd17f6bffb17b3e0c13ab.] Can you confirm and close the ticket if so please? > Support for Multi-Release-JARs > -- > > Key: MSHADE-385 > URL: https://issues.apache.org/jira/browse/MSHADE-385 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.3.0 >Reporter: Markus Karg >Priority: Major > > Maven Shade Plugin currently is unable to deal with multi-release JARs, hence > it always (and only) picks the lowest commen nominator (fallback) class. > > Actually the plugin should instead produce a multi-release JAR, hence pick > all class versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] mkarg commented on pull request #421: Artifact.getPath() and .setPath()
mkarg commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-808925420 The contract is: * There is *one single* property, which is named `file`, and it has the getters and setters `getFile` and `setFile`, and the contract is that `getFile` returns `setFile`. This already existed and is tested, so there is no need to test *that* contract again. * There is **no** separate property named `path`. `getPath` simply is *an alias* for `getFile`, and `setPath` is *an alias* for `setFile`, working on the existing (and tested) property `File`, but certainly doing conversion on the fly. This is **by intention** because the idea is **not** to have *two* properties, but to provide a smooth transition phase from the IO-era to the NIO-era, i. e. to **replace** `File` some fine day in the future. Hence it makes no sense to tests *again* whether the property works as expected, but it makes much sense to check if the alias really works as an alias. In addition, my new test *solely* tests the code *that I added*, and it only tests it for *what I itend to*. Hence, it proofs whether the new alias methods are there, and whether they really act as an *alias*. I deliberate *do not* test if `getPath` returns `setPath` as this would imply testing the `file` property (which is already tests). Also it is irrelevent if *some other* implementation of the interface would fail the tests, as I deliberate *do not* tests *some* implementation, but in fact, I *only* test the default alias implementation (not *any* alias implementation). Testing *other* implementations, or testing *other* scenario simply is out of scope of this PR, which *solely* has the intention to add the alias methods to the interface, if you remember. So if there is anything unclear about the intention of this PR, or if somebody has really a huge problem with this, then please tell now and clearly **what** problem does **actually** exist. Does this PR provide harm? No. Is it beneficial? Yes. Don't let us squander valuable time arguing about things *beyond* the scope of this PR. Let's focus on the merits of **this PR**, and let's move on, even if we have different likes or dislikes. Otherwise I would really like to kindly ask you to merge this PR (I am not a committer, someone of you need to do it). Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7121) better support for multiple JDK
[ https://issues.apache.org/jira/browse/MNG-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310157#comment-17310157 ] Martin Kanters commented on MNG-7121: - Fair enough. Perhaps someone could build something like this using extensions. > better support for multiple JDK > --- > > Key: MNG-7121 > URL: https://issues.apache.org/jira/browse/MNG-7121 > Project: Maven > Issue Type: New Feature > Components: core >Reporter: Pablo Grisafi >Priority: Major > > Java evolves at a much faster pace now. In the compay I work for we have > projects on Java 6 (sadly yes), 8, 11 and 15. > > The toolchains plugin helps, but it involves manually editing an xml file, > and in my experience people tend to forget about it. > > I think a better user experiense would be a ~/.m2/jdks folder, with one > subfolder per jdk, a little like sdkman does it. > Maven could even automaticlly download the one you need for a specific > project if it is not already present, like it does with any dependency. It > will be more portable and less manual work. Dependency handling and jdk > handling will be managed be maven in a consistent way, cloning a project from > github will be way more straightforward. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1897) Incorrect classpath due to JPMS magic
[
https://issues.apache.org/jira/browse/SUREFIRE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1897:
---
Fix Version/s: 3.0.0-M6
> Incorrect classpath due to JPMS magic
> -
>
> Key: SUREFIRE-1897
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1897
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> I converted my project to use CI friendly maven:
> [https://maven.apache.org/maven-ci-friendly.html]
> To fully simplify and get around bugs in M2E (maven eclipse plugin) I went
> away maintaining the version in .mvn/maven.config and simply set "revision"
> to "0-SNAPSHOT" in my parent POMs. When I build a release, I can override the
> "revision" to the actual release version.
> As a result now maven fails if I change the version of a sibling project I
> maintain and use to "0-SNAPSHOT" while the content of the code in the JARs
> has not changed at all.
> In the maven log I observed this warnings:
> {code:java}
> [WARNING] Can't extract module name from mmm-l10n-en-0-SNAPSHOT.jar:
> mmm.l10n.en.0.SNAPSHOT: Invalid module name: '0' is not a Java identifier
> [WARNING] Can't extract module name from mmm-l10n-de-0-SNAPSHOT.jar:
> mmm.l10n.de.0.SNAPSHOT: Invalid module name: '0' is not a Java identifier
> [WARNING] Can't extract module name from mmm-l10n-es-0-SNAPSHOT.jar:
> mmm.l10n.es.0.SNAPSHOT: Invalid module name: '0' is not a Java identifier
> [WARNING] Can't extract module name from mmm-l10n-fr-0-SNAPSHOT.jar:
> mmm.l10n.fr.0.SNAPSHOT: Invalid module name: '0' is not a Java identifier
> [WARNING] Can't extract module name from mmm-l10n-all-0-SNAPSHOT.jar:
> mmm.l10n.all.0.SNAPSHOT: Invalid module name: '0' is not a Java
> identifier{code}
> I launched the maven build with debugging (-X) both with the previous version
> 0.2.1-SNAPSHOT (working) and with 0-SNAPSHOT (failing). Here are the
> surefireargs for both variants:
> WORKING (0.2.1-SNAPSHOT dependency):
> {code:java}
> --module-path
> /Users/hohwille/projects/mmm/workspaces/main/nls/core/target/classes
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-scanner/0.2.1-SNAPSHOT/mmm-scanner-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-base/0.2.1-SNAPSHOT/mmm-base-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/org/slf4j/slf4j-api/2.0.0-alpha1/slf4j-api-2.0.0-alpha1.jar
> --class-path
> /Users/hohwille/.m2/repository/org/apache/maven/surefire/surefire-booter/2.22.2/surefire-booter-2.22.2.jar
> :/Users/hohwille/.m2/repository/org/apache/maven/surefire/surefire-api/2.22.2/surefire-api-2.22.2.jar
> :/Users/hohwille/.m2/repository/org/apache/maven/surefire/surefire-logger-api/2.22.2/surefire-logger-api-2.22.2.jar
> :/Users/hohwille/projects/mmm/workspaces/main/nls/core/target/test-classes:/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-l10n-all/0.2.1-SNAPSHOT/mmm-l10n-all-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-l10n-de/0.2.1-SNAPSHOT/mmm-l10n-de-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-l10n-en/0.2.1-SNAPSHOT/mmm-l10n-en-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-l10n-es/0.2.1-SNAPSHOT/mmm-l10n-es-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/io/github/m-m-m/mmm-l10n-fr/0.2.1-SNAPSHOT/mmm-l10n-fr-0.2.1-SNAPSHOT.jar
> :/Users/hohwille/.m2/repository/org/junit/jupiter/junit-jupiter/5.7.0/junit-jupiter-5.7.0.jar
> :/Users/hohwille/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.7.0/junit-jupiter-api-5.7.0.jar
> :/Users/hohwille/.m2/repository/org/apiguardian/apiguardian-api/1.1.0/apiguardian-api-1.1.0.jar
> :/Users/hohwille/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
> :/Users/hohwille/.m2/repository/org/junit/platform/junit-platform-commons/1.7.0/junit-platform-commons-1.7.0.jar
> :/Users/hohwille/.m2/repository/org/junit/jupiter/junit-jupiter-params/5.7.0/junit-jupiter-params-5.7.0.jar
> :/Users/hohwille/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.7.0/junit-jupiter-engine-5.7.0.jar
> :/Users/hohwille/.m2/repository/org/junit/platform/junit-platform-engine/1.7.0/junit-platform-engine-1.7.0.jar
> :/Users/hohwille/.m2/repository/org/assertj/assertj-core/3.19.0/assertj-core-3.19.0.jar
> :/Users/hohwille/.m2/repository/ch/qos/logback/logback-classic/1.3.0-alpha5/logback-classic-1.3.0-alpha5.jar
> :/Users/hohwille/.m2/repository/ch/qos/logback/logback-core/1.3.0-alpha5/logback-core-1.3.0-alpha5.jar
> :/Users/hohwille/.m2/repository/com/sun/mail/javax.mail/1.6.2/javax.mail-1.6.2.jar
> :/Users/hohwille/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
> :/Users/hohwille/.m2/repository/edu/washington/cs/types/checker/checker-framework/1.7.0
[jira] [Updated] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1659:
---
Fix Version/s: 3.0.0-M6
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #342: [SUREFIRE-1659] Log4j logger in TestExecutionListener corrupts Surefire's STDOUT
Tibor17 commented on pull request #342: URL: https://github.com/apache/maven-surefire/pull/342#issuecomment-808871391 @kalgon Can you extend the integration test `JUnitPlatformStreamCorruptionIT`? Its purpose is to assert that the console logs do not contain the message `Corrupted channel by directly writing to native stream in forked JVM`. The POM and project which is tested by this IT appears in `surefire-its/src/test/resources/surefire-1614-stream-corruption`. All you need to do is to add a new maven profile in the `pom.xml` and the motivation can be found in the [comment](https://issues.apache.org/jira/browse/SUREFIRE-1659?focusedCommentId=17075165&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17075165) where you can see the zip file `src.zip`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #342: [SUREFIRE-1659] Log4j logger in TestExecutionListener corrupts Surefire's STDOUT
Tibor17 commented on a change in pull request #342: URL: https://github.com/apache/maven-surefire/pull/342#discussion_r602853109 ## File path: surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/LazyLauncher.java ## @@ -0,0 +1,60 @@ +package org.apache.maven.surefire.junitplatform; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.junit.platform.launcher.Launcher; +import org.junit.platform.launcher.LauncherDiscoveryRequest; +import org.junit.platform.launcher.TestExecutionListener; +import org.junit.platform.launcher.TestPlan; +import org.junit.platform.launcher.core.LauncherFactory; + +class LazyLauncher implements Launcher Review comment: Pls put a Javadoc for the class with the purpose of the class. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1659:
--
Assignee: Tibor Digana
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
