[GitHub] [maven-surefire] andpab opened a new pull request, #591: [SUREFIRE-2139] Raise asm to 9.4 for proper Java 19/20 bytecode support
andpab opened a new pull request, #591: URL: https://github.com/apache/maven-surefire/pull/591 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] michael-o merged pull request #359: Fix formatting to have XML rendered correctly
michael-o merged PR #359: URL: https://github.com/apache/maven-site/pull/359 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] michael-o merged pull request #357: Fix formatting to have XML rendered correctly
michael-o merged PR #357: URL: https://github.com/apache/maven-site/pull/357 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] asfgit merged pull request #356: Add release notes for Maven 3.8.7
asfgit merged PR #356: URL: https://github.com/apache/maven-site/pull/356 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2139) Fully support Java 19 byte code
[
https://issues.apache.org/jira/browse/SUREFIRE-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Pabst updated SUREFIRE-2139:
Description:
The examples from Surefire's [JPMS
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html]
do not work if they are compiled with language level 19.
This behaviour can also be reproduced by executing the JPMS-related ITs with
Java 19, for example MultiModuleProjectWithJPMSIT.
h3. Root cause
The root cause appears to be an ASM 9.2 dependency that does not support Java
19 bytecode. The ASM dependency comes in transitively via plexus-java 1.1.1.
h3. Workaround
A workaround for 3.0.0-M7 users is to explicitly add an ASM 9.3 or 9.4
dependency to the maven-surefire-plugin configuration like this:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
org.ow2.asm
asm
9.3
{code}
h3. Options for fixing
To properly fix it there are two options:
1. The ASM version could be set to 9.3 or 9.4 in the dependencyManagement
section of the main pom.xml
2. The plexus-java dependency in maven-surefire-common could be upgraded to an
as of now yet to be released new version of plexus-java that brings in ASM in
version 9.4 (master branch already has it).
was:
The examples from Surefire's [JPMS
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html]
do not work if they are compiled with language level 19.
This behaviour can also be reproduced by executing the JPMS-related ITs with
Java 19, for example MultiModuleProjectWithJPMSIT.
The root cause appears to be an ASM 9.2 dependency that does not support Java
19 bytecode. The ASM dependency comes in transitively via plexus-java 1.1.1.
A workaround for 3.0.0-M7 users is to explicitly add an ASM 9.3 or 9.4
dependency to the maven-surefire-plugin configuration like this:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
org.ow2.asm
asm
9.3
{code}
To properly fix it, the ASM version could be set to 9.3 or 9.4 in the
dependencyManagement section of the main pom.xml or the plexus-java dependency
in maven-surefire-common could be upgraded to an as of now yet to be released
new version of plexus-java that brings in ASM in version 9.4.
> Fully support Java 19 byte code
> ---
>
> Key: SUREFIRE-2139
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2139
> Project: Maven Surefire
> Issue Type: New Feature
> Components: classloading
>Reporter: Andreas Pabst
>Priority: Major
> Labels: jdk19, jigsaw, jpms
>
> The examples from Surefire's [JPMS
> documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html]
> do not work if they are compiled with language level 19.
> This behaviour can also be reproduced by executing the JPMS-related ITs with
> Java 19, for example MultiModuleProjectWithJPMSIT.
> h3. Root cause
> The root cause appears to be an ASM 9.2 dependency that does not support Java
> 19 bytecode. The ASM dependency comes in transitively via plexus-java 1.1.1.
> h3. Workaround
> A workaround for 3.0.0-M7 users is to explicitly add an ASM 9.3 or 9.4
> dependency to the maven-surefire-plugin configuration like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M7
>
>
> org.ow2.asm
> asm
> 9.3
>
>
>
> {code}
> h3. Options for fixing
> To properly fix it there are two options:
> 1. The ASM version could be set to 9.3 or 9.4 in the dependencyManagement
> section of the main pom.xml
> 2. The plexus-java dependency in maven-surefire-common could be upgraded to
> an as of now yet to be released new version of plexus-java that brings in ASM
> in version 9.4 (master branch already has it).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] andpab commented on pull request #565: add jdk 19
andpab commented on PR #565: URL: https://github.com/apache/maven-surefire/pull/565#issuecomment-1368091463 I rebased this branch to master locally and ran the ITs. Most of them are successful except for 6 JPMS-related ITs: - MultiModuleProjectWithJPMSIT - Surefire1570ModularFailsafeIT - Surefire1712ExtractedModulenameWithoutASMIT - Surefire1733JUnitIT - Surefire1733TestngIT - Surefire1993JpmsProvidingModulesIT They fail because the modules are not detected. Changing the `maven.compiler.release` property from 19 to 18 in the test projects made the tests succeed. Looked like Surefire having a problem with JDK19-level bytecode for projects using JPMS, so I checked the dependency tree. It has ASM in version 9.2, coming in transitively via plexus-java-1.1.1. ASM 9.2 does not support JDK19 byte code. I set ASM to 9.4 in the dependencyManagement section of the main pom.xml and the ITs were successful. I've created a JIRA issue for it which also documents the two options for fixing the issue: SUREFIRE-2139 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SUREFIRE-2139) Fully support Java 19 byte code
Andreas Pabst created SUREFIRE-2139:
---
Summary: Fully support Java 19 byte code
Key: SUREFIRE-2139
URL: https://issues.apache.org/jira/browse/SUREFIRE-2139
Project: Maven Surefire
Issue Type: New Feature
Components: classloading
Reporter: Andreas Pabst
The examples from Surefire's [JPMS
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html]
do not work if they are compiled with language level 19.
This behaviour can also be reproduced by executing the JPMS-related ITs with
Java 19, for example MultiModuleProjectWithJPMSIT.
The root cause appears to be an ASM 9.2 dependency that does not support Java
19 bytecode. The ASM dependency comes in transitively via plexus-java 1.1.1.
A workaround for 3.0.0-M7 users is to explicitly add an ASM 9.3 or 9.4
dependency to the maven-surefire-plugin configuration like this:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
org.ow2.asm
asm
9.3
{code}
To properly fix it, the ASM version could be set to 9.3 or 9.4 in the
dependencyManagement section of the main pom.xml or the plexus-java dependency
in maven-surefire-common could be upgraded to an as of now yet to be released
new version of plexus-java that brings in ASM in version 9.4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] andpab commented on a diff in pull request #554: [SUREFIRE-2109] Add suffix derived from current user to Surefire temp directory name and make directory writable for all
andpab commented on code in PR #554: URL: https://github.com/apache/maven-surefire/pull/554#discussion_r1059513138 ## surefire-api/src/main/java/org/apache/maven/surefire/api/util/TempFileManager.java: ## @@ -180,6 +180,8 @@ public synchronized File createTempFile( String prefix, String suffix ) throw new UncheckedIOException( new IOException( "Unable to create temporary directory " + tempDir.getAbsolutePath() ) ); } +// try to make temp file directory writable for all +tempDir.setWritable( true, false ); Review Comment: Thanks for the explanation. I understand the rationale now, but what about the scenario that `java.io.tmpdir` is set to a user-specific location in an otherwise protected area? I still think there should be a difference in scrutiny applied between writing to a destination that is already world-writable by design and explicitly making the destination world-writable. How about passing the username through `URLEncoder#encode` instead of removing special characters? That is guaranteed to create a directory name that is collision-free and valid on all file systems. It also handles the issue immediately at the code location where it arises rather than working around it somewhere else in a manner that is not particularly easy to grasp. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7222) Validate and warn for naming collisions between Maven and System properties
[
https://issues.apache.org/jira/browse/MNG-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7222:
Fix Version/s: waiting-for-feedback
> Validate and warn for naming collisions between Maven and System properties
> ---
>
> Key: MNG-7222
> URL: https://issues.apache.org/jira/browse/MNG-7222
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> As properties referenced via {{${x}}} are first being resolved against system
> properties and only afterwards against Maven properties according to
> https://maven.apache.org/pom.html#properties. As this is often not noticed
> such collisions should be detected by Maven and lead to a WARN.
> An example for such a collision can be seen at
> https://github.com/adobe/aem-core-wcm-components/blob/6a294b0483c711a0283474f962a4643234e47c6e/parent/pom.xml#L64
> which is never effective as this is always overridden by
> https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
> At least the mandatory properties (available on all JREs) outlined at
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties--
> should always lead to a WARN.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7222) Validate and warn for naming collisions between Maven and System properties
[
https://issues.apache.org/jira/browse/MNG-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653179#comment-17653179
]
Michael Osipov commented on MNG-7222:
-
I have been working in some properties related improvement recently. Which
dominant/recessive sources should be evaluted to override properties?
* Model properties overwrite system properties?
* User properties overwriting system properties?
I think enumeration of combos is complete.
> Validate and warn for naming collisions between Maven and System properties
> ---
>
> Key: MNG-7222
> URL: https://issues.apache.org/jira/browse/MNG-7222
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Priority: Major
>
> As properties referenced via {{${x}}} are first being resolved against system
> properties and only afterwards against Maven properties according to
> https://maven.apache.org/pom.html#properties. As this is often not noticed
> such collisions should be detected by Maven and lead to a WARN.
> An example for such a collision can be seen at
> https://github.com/adobe/aem-core-wcm-components/blob/6a294b0483c711a0283474f962a4643234e47c6e/parent/pom.xml#L64
> which is never effective as this is always overridden by
> https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
> At least the mandatory properties (available on all JREs) outlined at
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getProperties--
> should always lead to a WARN.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7656) Dependencies copied to target have stricter permissions
[
https://issues.apache.org/jira/browse/MNG-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653177#comment-17653177
]
Michael Osipov commented on MNG-7656:
-
Alright, will stay put and wait for the logs. Gut Shabbos.
> Dependencies copied to target have stricter permissions
> ---
>
> Key: MNG-7656
> URL: https://issues.apache.org/jira/browse/MNG-7656
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-3
>Reporter: Moshe Elisha
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> Dependency JARs that were copied during "clean install" to target have read
> and write permissions only to the user/owner and no permissions at all to the
> group and others.("-rw---")
> Not sure if the issue is when maven downloads the JARs from the repo or when
> the JARs are copied from the repo to the target (using
> "dependency:3.4.0:copy-dependencies")
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7656) Dependencies copied to target have stricter permissions
[
https://issues.apache.org/jira/browse/MNG-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7656:
Fix Version/s: waiting-for-feedback
> Dependencies copied to target have stricter permissions
> ---
>
> Key: MNG-7656
> URL: https://issues.apache.org/jira/browse/MNG-7656
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-3
>Reporter: Moshe Elisha
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> Dependency JARs that were copied during "clean install" to target have read
> and write permissions only to the user/owner and no permissions at all to the
> group and others.("-rw---")
> Not sure if the issue is when maven downloads the JARs from the repo or when
> the JARs are copied from the repo to the target (using
> "dependency:3.4.0:copy-dependencies")
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on a diff in pull request #214: MENFORCER-435: Fixing unit tests
ajarmoniuk commented on code in PR #214: URL: https://github.com/apache/maven-enforcer/pull/214#discussion_r1059493012 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependenciesBase.java: ## @@ -20,12 +20,12 @@ import java.util.List; -import org.apache.commons.lang3.StringUtils; import org.apache.maven.artifact.Artifact; import org.apache.maven.enforcer.rule.api.EnforcerRuleException; import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper; import org.apache.maven.execution.MavenSession; import org.apache.maven.plugins.enforcer.utils.ArtifactUtils; +import org.apache.maven.shared.utils.StringUtils; Review Comment: Even worse. The reason was my IDE changing it to Google something during a failed rebase, which was the reason for the red build. Corrected. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski commented on a diff in pull request #214: MENFORCER-435: Fixing unit tests
slawekjaranowski commented on code in PR #214: URL: https://github.com/apache/maven-enforcer/pull/214#discussion_r1059488879 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependenciesBase.java: ## @@ -20,12 +20,12 @@ import java.util.List; -import org.apache.commons.lang3.StringUtils; import org.apache.maven.artifact.Artifact; import org.apache.maven.enforcer.rule.api.EnforcerRuleException; import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper; import org.apache.maven.execution.MavenSession; import org.apache.maven.plugins.enforcer.utils.ArtifactUtils; +import org.apache.maven.shared.utils.StringUtils; Review Comment: Why change commons-lang to Maven shared? Even more I would to like remove Maven shared from dependencies in the future. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653162#comment-17653162
]
ASF GitHub Bot commented on DOXIA-617:
--
michael-o commented on PR #132:
URL: https://github.com/apache/maven-doxia/pull/132#issuecomment-1368019605
> @hboutemy This is a very good point. It's better to keep backward
compatibility as long as it doesn't make our code too complex.
>
> In this case, we could use a simple replace regex to add the `---` markers
when we detect the old-style header. Something like
`^(?:(\s*[a-zA-Z0-9_\-]+\s*:.*\R)+)\R(.*)` ==> `---\n$1---\n$2`
>
> (ha ha, isn't the above regex charming? 🤦♂️)
regex pr0n!
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: 1.12.0, 2.0.0-M5
>
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] michael-o commented on pull request #132: [DOXIA-617] support yaml metadata
michael-o commented on PR #132: URL: https://github.com/apache/maven-doxia/pull/132#issuecomment-1368019605 > @hboutemy This is a very good point. It's better to keep backward compatibility as long as it doesn't make our code too complex. > > In this case, we could use a simple replace regex to add the `---` markers when we detect the old-style header. Something like `^(?:(\s*[a-zA-Z0-9_\-]+\s*:.*\R)+)\R(.*)` ==> `---\n$1---\n$2` > > (ha ha, isn't the above regex charming? 🤦♂️) regex pr0n! -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-445) Include Java Home in Message for Java Rule Failures
[
https://issues.apache.org/jira/browse/MENFORCER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653155#comment-17653155
]
Petr Široký commented on MENFORCER-445:
---
The error messages now look like this (unless there is a custom message
provided with the rule configuration):
{code:java}
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed
with message:
Detected JDK version 11.0.17
(JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.17.0.8-1.fc37.x86_64) is not in
the allowed range 17.
[ERROR] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVendor failed with
message:
Red Hat, Inc. is not an included Required Java Vendor
(JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.17.0.8-1.fc37.x86_64){code}
> Include Java Home in Message for Java Rule Failures
> ---
>
> Key: MENFORCER-445
> URL: https://issues.apache.org/jira/browse/MENFORCER-445
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Documentation, Standard Rules
>Affects Versions: 3.1.0
> Environment: Maven 3.8.5
>Reporter: Robert Krajewski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Labels: enforcer, messages, up-for-grabs, usability
> Fix For: 3.2.0
>
>
> When Java rules fail, for example, when JDK version or vendor fails, knowing
> exactly which Java implementation caused the problem would be handy,
> especially when it happens in a CI system that might be setting up the Java
> to be used in a roundabout way. Including the Java home in the message should
> be enough.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-shade-plugin] pzygielo commented on pull request #171: Update overlapping resources warning
pzygielo commented on PR #171: URL: https://github.com/apache/maven-shade-plugin/pull/171#issuecomment-1367972060 Thanks for checking. Probably just "file" would be even better indeed! -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MENFORCER-445) Include Java Home in Message for Java Rule Failures
[ https://issues.apache.org/jira/browse/MENFORCER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MENFORCER-445. - Fix Version/s: 3.2.0 Assignee: Slawomir Jaranowski Resolution: Fixed > Include Java Home in Message for Java Rule Failures > --- > > Key: MENFORCER-445 > URL: https://issues.apache.org/jira/browse/MENFORCER-445 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 3.1.0 > Environment: Maven 3.8.5 >Reporter: Robert Krajewski >Assignee: Slawomir Jaranowski >Priority: Major > Labels: enforcer, messages, up-for-grabs, usability > Fix For: 3.2.0 > > > When Java rules fail, for example, when JDK version or vendor fails, knowing > exactly which Java implementation caused the problem would be handy, > especially when it happens in a CI system that might be setting up the Java > to be used in a roundabout way. Including the Java home in the message should > be enough. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
slawekjaranowski merged PR #213: URL: https://github.com/apache/maven-enforcer/pull/213 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (DOXIATOOLS-68) Update HttpComponents HttpClient 5.1
[ https://issues.apache.org/jira/browse/DOXIATOOLS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed DOXIATOOLS-68. -- Resolution: Fixed > Update HttpComponents HttpClient 5.1 > > > Key: DOXIATOOLS-68 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-68 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Linkcheck >Affects Versions: doxia-linkcheck-1.2 >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: doxia-linkcheck-1.3 > > > Currently uses 3.1 from 2007. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIATOOLS-68) Update HttpComponents HttpClient 5.1
[ https://issues.apache.org/jira/browse/DOXIATOOLS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated DOXIATOOLS-68: --- Summary: Update HttpComponents HttpClient 5.1 (was: Update HttpComponents HttpClient 4.5.x) > Update HttpComponents HttpClient 5.1 > > > Key: DOXIATOOLS-68 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-68 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Linkcheck >Affects Versions: doxia-linkcheck-1.2 >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: doxia-linkcheck-1.3 > > > Currently uses 3.1 from 2007. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #214: MENFORCER-435: Fixing unit tests
ajarmoniuk commented on PR #214: URL: https://github.com/apache/maven-enforcer/pull/214#issuecomment-1367942567 @slawekjaranowski fixes the unit test problems you spotted. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk opened a new pull request, #214: MENFORCER-435: Fixing unit tests
ajarmoniuk opened a new pull request, #214: URL: https://github.com/apache/maven-enforcer/pull/214 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] pzygielo opened a new pull request, #171: Update overlapping resources warning
pzygielo opened a new pull request, #171: URL: https://github.com/apache/maven-shade-plugin/pull/171 - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] sman-81 commented on a diff in pull request #554: [SUREFIRE-2109] Add suffix derived from current user to Surefire temp directory name and make directory writable for all
sman-81 commented on code in PR #554: URL: https://github.com/apache/maven-surefire/pull/554#discussion_r1059393355 ## surefire-api/src/main/java/org/apache/maven/surefire/api/util/TempFileManager.java: ## @@ -180,6 +180,8 @@ public synchronized File createTempFile( String prefix, String suffix ) throw new UncheckedIOException( new IOException( "Unable to create temporary directory " + tempDir.getAbsolutePath() ) ); } +// try to make temp file directory writable for all +tempDir.setWritable( true, false ); Review Comment: The aim of the original PR was to stop Surefire from bloating the system temp directory by instead having it write into a subdirectory 'surefire'. The subdirectory was only writeable by the user that created it. So Surefire would fail if another user ran tests on the same machine (before reboot or otherwise cleaning up temp). Thus the user suffix is introduced by this PR. As user names may contain characters illegal in directory names, there is a risk, even though small or theoretic, that two users have identically names temp subdirectories. By making the directory writeable for all, this risk is eliminated. Until very recently Surefire wrote to system temp which by definition is shared by all users and was never a security concern to anyone. This PR leaves this semantic untouched. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
slawekjaranowski commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059381501
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
simply set if current message is null
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] psiroky commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
psiroky commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059372306
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
No, definitely not intentional. Just and oversight.
Would it make sense to override the message only if it has not been provided
by the rule configuration? Otherwise I am not sure how else would we get the
additional info in.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] psiroky commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
psiroky commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059372306
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
Hmm. So would it make sense to override the message only if it has not been
provided by the rule configuration? Otherwise I am not sure how else would we
get the additional info in.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] psiroky commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
psiroky commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059372306
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
Hmm. So would it make sense to override the message only if it has not been
provided by the rule configuration? Otherwise I am not sure how else would be
get the additional info in.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] psiroky commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
psiroky commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059372306
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
Hmm. So would it make sense to override the message only if it has been not
provided by the rule configuration? Otherwise I am not sure how else would be
get the additional info in.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653124#comment-17653124
]
ASF GitHub Bot commented on DOXIA-617:
--
bertysentry commented on PR #132:
URL: https://github.com/apache/maven-doxia/pull/132#issuecomment-1367895354
@hboutemy This is a very good point. It's better to keep backward
compatibility as long as it doesn't make our code too complex.
In this case, we could use a simple replace regex to add the `---` markers
when we detect the old-style header. Something like
`^(?:(\s*[a-zA-Z0-9_\-]+\s*:.*\R)+)\R(.*)` ==> `---\n$1---\n$2`
(ha ha, isn't the above regex charming? 🤦♂️)
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
> Fix For: 1.12.0, 2.0.0-M5
>
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] bertysentry commented on pull request #132: [DOXIA-617] support yaml metadata
bertysentry commented on PR #132: URL: https://github.com/apache/maven-doxia/pull/132#issuecomment-1367895354 @hboutemy This is a very good point. It's better to keep backward compatibility as long as it doesn't make our code too complex. In this case, we could use a simple replace regex to add the `---` markers when we detect the old-style header. Something like `^(?:(\s*[a-zA-Z0-9_\-]+\s*:.*\R)+)\R(.*)` ==> `---\n$1---\n$2` (ha ha, isn't the above regex charming? 🤦♂️) -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski commented on a diff in pull request #213: [MENFORCER-445] Include JAVA_HOME location in the Java rule failure messages
slawekjaranowski commented on code in PR #213:
URL: https://github.com/apache/maven-enforcer/pull/213#discussion_r1059370417
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java:
##
@@ -76,6 +76,7 @@ public void execute(EnforcerRuleHelper helper) throws
EnforcerRuleException {
+ " Build: " + detectedJdkVersion.getBuildNumber() + "
Qualifier: "
+ detectedJdkVersion.getQualifier());
+super.setMessage(prepareMessage(detectedJdkVersion, getVersion()));
Review Comment:
We override message which can be provided by rule configuration - is it
intentionally?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7656) Dependencies copied to target have stricter permissions
[
https://issues.apache.org/jira/browse/MNG-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653117#comment-17653117
]
Moshe Elisha commented on MNG-7656:
---
Shalom. Thank you for the quick reply.
We have a relative simple pom with a JAR dependency and a
"maven-dependency-plugin" that "copy-dependencies" to the target folder.
We noticed there was a change in the JAR permissions.
I will try to get logs soon. We recently upgraded from alpha-2 to alpha-3 but I
will also check if something changed in the operating system itself.
> Dependencies copied to target have stricter permissions
> ---
>
> Key: MNG-7656
> URL: https://issues.apache.org/jira/browse/MNG-7656
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-3
>Reporter: Moshe Elisha
>Priority: Minor
>
> Dependency JARs that were copied during "clean install" to target have read
> and write permissions only to the user/owner and no permissions at all to the
> group and others.("-rw---")
> Not sure if the issue is when maven downloads the JARs from the repo or when
> the JARs are copied from the repo to the target (using
> "dependency:3.4.0:copy-dependencies")
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7656) Dependencies copied to target have stricter permissions
[
https://issues.apache.org/jira/browse/MNG-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653100#comment-17653100
]
Michael Osipov commented on MNG-7656:
-
Shalom Moshe, copied from where? Please show ls output from before and after.
We don't set mod explicitly, but rely implicitly on umask.
> Dependencies copied to target have stricter permissions
> ---
>
> Key: MNG-7656
> URL: https://issues.apache.org/jira/browse/MNG-7656
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-3
>Reporter: Moshe Elisha
>Priority: Minor
>
> Dependency JARs that were copied during "clean install" to target have read
> and write permissions only to the user/owner and no permissions at all to the
> group and others.("-rw---")
> Not sure if the issue is when maven downloads the JARs from the repo or when
> the JARs are copied from the repo to the target (using
> "dependency:3.4.0:copy-dependencies")
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653082#comment-17653082
]
ASF GitHub Bot commented on MNG-7655:
-
hboutemy commented on PR #942:
URL: https://github.com/apache/maven/pull/942#issuecomment-1367816557
ok, launching some feedback on the Maven dev ML for plexus-xml: this looks
simple and wold make things much cleaner = Plexus plexus-utils 4 is used as is
(and eventually migrated away), and there is only the plexus-xml
reimplementation as maven-plexus-xml
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hboutemy commented on pull request #942: [MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)
hboutemy commented on PR #942: URL: https://github.com/apache/maven/pull/942#issuecomment-1367816557 ok, launching some feedback on the Maven dev ML for plexus-xml: this looks simple and wold make things much cleaner = Plexus plexus-utils 4 is used as is (and eventually migrated away), and there is only the plexus-xml reimplementation as maven-plexus-xml -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia-converter] kwin commented on pull request #32: [DOXIATOOLS-73] Drop support for Converting Confluence documents
kwin commented on PR #32: URL: https://github.com/apache/maven-doxia-converter/pull/32#issuecomment-1367815612 @michael-o @slachiewicz Given that there will be a new release for https://issues.apache.org/jira/browse/DOXIATOOLS-74 should we reopen and merge? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski commented on pull request #202: [MENFORCER-435] Remove not needed maven-dependency-tree and maven-compat
slawekjaranowski commented on PR #202: URL: https://github.com/apache/maven-enforcer/pull/202#issuecomment-1367813010 It is valid questions. I added comments on commit ... https://github.com/apache/maven-enforcer/commit/919fe02a0fe92a055a6e24dff04fb9c7618954f4 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-302) Introduce onSession close
[
https://issues.apache.org/jira/browse/MRESOLVER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653080#comment-17653080
]
ASF GitHub Bot commented on MRESOLVER-302:
--
kwin commented on code in PR #232:
URL: https://github.com/apache/maven-resolver/pull/232#discussion_r1059306441
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystem.java:
##
@@ -302,4 +302,39 @@ List newResolutionRepositories(
RepositorySystemSession sessio
* @since 1.9.0
*/
void shutdown();
+
+/**
+ * Registers the session for lifecycle tracking: it marks that the passed
in session instance is about to start.
+ * After this call it is possible to register "on close" handlers using
+ * {@link #addOnSessionEndedHandle(RepositorySystemSession, Runnable)}
method that will execute once
+ * {@link #sessionEnded(RepositorySystemSession)} method was invoked.
+ *
+ * Same session instance can be started only once.
+ *
+ * @param session the session that is about to start, never {@code null}.
+ * @since TBD
+ */
+void sessionStarted( RepositorySystemSession session );
+
+/**
+ * Registers a handler to execute when this session ends. This method
throws, if the passed in session instance
+ * was not passed to method {@link
#sessionStarted(RepositorySystemSession)} beforehand.
+ *
+ * @param session the session for which the handler needs to be
registered, never {@code null}.
+ * @param handler the handler, never {@code null}.
+ * @since TBD
+ */
+void addOnSessionEndedHandle( RepositorySystemSession session, Runnable
handler );
+
+/**
+ * Signals to repository system that passed in session ended, it will not
be used anymore. Repository system
+ * will invoke the registered handlers for this session, if any. This
method throws if the passed in session
+ * instance was not passed to method {@link
#sessionStarted(RepositorySystemSession)} beforehand.
+ *
+ * Same session instance can be ended only once.
+ *
+ * @param session the session that just ended, never {@code null}.
+ * @since TBD
+ */
+void sessionEnded( RepositorySystemSession session );
Review Comment:
Understood, but the same uncertainty is now applicable to
`sessionEnded(...)`. When should consumers call it? What about sessions created
with
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/DefaultRepositorySystemSession.html#%3Cinit%3E(org.eclipse.aether.RepositorySystemSession)?
What about forwarding sessions. The Javadocs need to be extended in this
regard.
> Introduce onSession close
> -
>
> Key: MRESOLVER-302
> URL: https://issues.apache.org/jira/browse/MRESOLVER-302
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.3
>
>
> The on session close callback, revisited.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] kwin commented on a diff in pull request #232: [MRESOLVER-302] Introduce onSessionClose hooks
kwin commented on code in PR #232:
URL: https://github.com/apache/maven-resolver/pull/232#discussion_r1059306441
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystem.java:
##
@@ -302,4 +302,39 @@ List newResolutionRepositories(
RepositorySystemSession sessio
* @since 1.9.0
*/
void shutdown();
+
+/**
+ * Registers the session for lifecycle tracking: it marks that the passed
in session instance is about to start.
+ * After this call it is possible to register "on close" handlers using
+ * {@link #addOnSessionEndedHandle(RepositorySystemSession, Runnable)}
method that will execute once
+ * {@link #sessionEnded(RepositorySystemSession)} method was invoked.
+ *
+ * Same session instance can be started only once.
+ *
+ * @param session the session that is about to start, never {@code null}.
+ * @since TBD
+ */
+void sessionStarted( RepositorySystemSession session );
+
+/**
+ * Registers a handler to execute when this session ends. This method
throws, if the passed in session instance
+ * was not passed to method {@link
#sessionStarted(RepositorySystemSession)} beforehand.
+ *
+ * @param session the session for which the handler needs to be
registered, never {@code null}.
+ * @param handler the handler, never {@code null}.
+ * @since TBD
+ */
+void addOnSessionEndedHandle( RepositorySystemSession session, Runnable
handler );
+
+/**
+ * Signals to repository system that passed in session ended, it will not
be used anymore. Repository system
+ * will invoke the registered handlers for this session, if any. This
method throws if the passed in session
+ * instance was not passed to method {@link
#sessionStarted(RepositorySystemSession)} beforehand.
+ *
+ * Same session instance can be ended only once.
+ *
+ * @param session the session that just ended, never {@code null}.
+ * @since TBD
+ */
+void sessionEnded( RepositorySystemSession session );
Review Comment:
Understood, but the same uncertainty is now applicable to
`sessionEnded(...)`. When should consumers call it? What about sessions created
with
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/DefaultRepositorySystemSession.html#%3Cinit%3E(org.eclipse.aether.RepositorySystemSession)?
What about forwarding sessions. The Javadocs need to be extended in this
regard.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #202: [MENFORCER-435] Remove not needed maven-dependency-tree and maven-compat
ajarmoniuk commented on PR #202: URL: https://github.com/apache/maven-enforcer/pull/202#issuecomment-1367811899 Can't see them anywhere. I only got a notification about new comments, but there were nowhere to be seen. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #202: [MENFORCER-435] Remove not needed maven-dependency-tree and maven-compat
ajarmoniuk commented on PR #202: URL: https://github.com/apache/maven-enforcer/pull/202#issuecomment-1367811069 > [@ajarmoniuk](https://github.com/ajarmoniuk) - can you check it, looks strange > I also afraid that IT test - require-release-dependencies check nothing - there is no dependencies in test also > In unit test I see: > [INFO] Running org.apache.maven.plugins.enforcer.TestRequireReleaseDeps [debug] groupId:artifactId:jar:classifier:version groupId:artifact:jar:classifier:1.0.0 <--- is not a release dependency groupId:artifact:jar:classifier:2.0.0 <--- is not a release dependency -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski commented on pull request #202: [MENFORCER-435] Remove not needed maven-dependency-tree and maven-compat
slawekjaranowski commented on PR #202: URL: https://github.com/apache/maven-enforcer/pull/202#issuecomment-1367809795 Which comments? I don't remember to remove something. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653070#comment-17653070
]
ASF GitHub Bot commented on MNG-7655:
-
hboutemy commented on PR #942:
URL: https://github.com/apache/maven/pull/942#issuecomment-1367796459
oh, back to plexus-utils https://codehaus-plexus.github.io/plexus-utils/ vs
maven-shared-utils https://maven.apache.org/shared/maven-shared-utils/
discussion
I suppose we can split maven-shared-utils 3 into maven-shared-xml 4 +
maven-shared-utils 4
using maven-shared-utils 4 instead of plexus-utils 4 in Maven core is not an
issue
but switching to maven-shared-xml 4 is not possible, because there is a java
package change from plexus-xml 4
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hboutemy commented on pull request #942: [MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)
hboutemy commented on PR #942: URL: https://github.com/apache/maven/pull/942#issuecomment-1367796459 oh, back to plexus-utils https://codehaus-plexus.github.io/plexus-utils/ vs maven-shared-utils https://maven.apache.org/shared/maven-shared-utils/ discussion I suppose we can split maven-shared-utils 3 into maven-shared-xml 4 + maven-shared-utils 4 using maven-shared-utils 4 instead of plexus-utils 4 in Maven core is not an issue but switching to maven-shared-xml 4 is not possible, because there is a java package change from plexus-xml 4 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653068#comment-17653068
]
ASF GitHub Bot commented on MNG-7655:
-
rmannibucau commented on PR #942:
URL: https://github.com/apache/maven/pull/942#issuecomment-1367794025
+1 for maven to ingest used plexus classes rather than working on plexus off
radars for the long term (probably lazily, ie each time we need a change we
rather import the lib instead of patching+releasing it).
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #942: [MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)
rmannibucau commented on PR #942: URL: https://github.com/apache/maven/pull/942#issuecomment-1367794025 +1 for maven to ingest used plexus classes rather than working on plexus off radars for the long term (probably lazily, ie each time we need a change we rather import the lib instead of patching+releasing it). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653067#comment-17653067
]
ASF GitHub Bot commented on MNG-7655:
-
hboutemy commented on PR #942:
URL: https://github.com/apache/maven/pull/942#issuecomment-1367793268
yes, splitting Plexus' plexus-utils 4.0.0
https://github.com/codehaus-plexus/plexus-utils into plexus-xml + plexus-utils
makes sense
because AFAIK Maven core exports plexus-xml only, not the plexus-utils other
classes, which are only internal hidden utils
then on how to evolve plexus-xml extracted from plexus-utils with the
rewrite for Maven 4, good question
first issue created
https://github.com/codehaus-plexus/plexus-utils/issues/228
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hboutemy commented on pull request #942: [MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)
hboutemy commented on PR #942: URL: https://github.com/apache/maven/pull/942#issuecomment-1367793268 yes, splitting Plexus' plexus-utils 4.0.0 https://github.com/codehaus-plexus/plexus-utils into plexus-xml + plexus-utils makes sense because AFAIK Maven core exports plexus-xml only, not the plexus-utils other classes, which are only internal hidden utils then on how to evolve plexus-xml extracted from plexus-utils with the rewrite for Maven 4, good question first issue created https://github.com/codehaus-plexus/plexus-utils/issues/228 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653065#comment-17653065
]
ASF GitHub Bot commented on MNG-7655:
-
hboutemy commented on code in PR #942:
URL: https://github.com/apache/maven/pull/942#discussion_r1059289711
##
maven-plexus-utils-xml/pom.xml:
##
@@ -25,9 +25,10 @@ under the License.
4.0.0-alpha-4-SNAPSHOT
- maven-xml-impl
+ maven-plexus-utils-xml
- Maven XML Implementation
+ Maven Plexus Utils XML Implementation
+ Reimplementation of Plexus Utils XML classes using Maven 4
immutalbe XML API
Review Comment:
fixed
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Sub-task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hboutemy commented on a diff in pull request #942: [MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)
hboutemy commented on code in PR #942: URL: https://github.com/apache/maven/pull/942#discussion_r1059289711 ## maven-plexus-utils-xml/pom.xml: ## @@ -25,9 +25,10 @@ under the License. 4.0.0-alpha-4-SNAPSHOT - maven-xml-impl + maven-plexus-utils-xml - Maven XML Implementation + Maven Plexus Utils XML Implementation + Reimplementation of Plexus Utils XML classes using Maven 4 immutalbe XML API Review Comment: fixed -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7648) Generated model reader is not setting location information
[
https://issues.apache.org/jira/browse/MNG-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653064#comment-17653064
]
ASF GitHub Bot commented on MNG-7648:
-
pavelhoral opened a new pull request, #943:
URL: https://github.com/apache/maven/pull/943
This is backport / cherry-pick of #940.
--
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`,
where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA
issue.
- [x] Also format the first line of the commit message like `[MNG-XXX]
SUMMARY`.
Best practice is to use the JIRA issue title in both the pull request
title and in the first line of the commit message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Generated model reader is not setting location information
> --
>
> Key: MNG-7648
> URL: https://issues.apache.org/jira/browse/MNG-7648
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Pavel Horal
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0-candidate, 4.0.0-alpha-4, 4.0.0
>
>
> -Generated model reader is not setting {{location}} property -
> [https://github.com/apache/maven/blob/e73a0b00fde80c400a6d854ec0c2ba7436325eed/maven-toolchain-model/src/main/mdo/reader.vm#L683]
> .-
> Project model does not have location property in plugin execution (potential
> issue when merging model parent configuration?). This causes issues for
> example in Maven Enforcer Plugin which uses this information (see
> [MENFORCER-447|https://issues.apache.org/jira/browse/MENFORCER-447?focusedCommentId=17651671&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17651671]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] pavelhoral opened a new pull request, #943: [MNG-7648] Fix locationTracking in DefaultModelBuildingRequest copy constructor
pavelhoral opened a new pull request, #943: URL: https://github.com/apache/maven/pull/943 This is backport / cherry-pick of #940. -- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
