[jira] [Commented] (MARCHETYPES-82) generate maven.compiler.release property as comment
[ https://issues.apache.org/jira/browse/MARCHETYPES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807064#comment-17807064 ] ASF GitHub Bot commented on MARCHETYPES-82: --- hboutemy commented on PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#issuecomment-1893138996 Many people seem not to know about ` 11` adding a comment is just an idea to spread the knowledge you're right that if people grep, they'll need to take care about the comment eager to see feedback from others: is such a comment a benefit or more a problem? > generate maven.compiler.release property as comment > --- > > Key: MARCHETYPES-82 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-82 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > if JDK 11+ is used to compile, it's better to define maven.compiler.release > instead of maven.compiler.source/target > we currently generate for Java 8, so we don't really know if the compiler > used support release parameter > adding a comment is a good first step to help discovery, before benefiting > from MARCHETYPES-70 when generating against newer JDK -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
hboutemy commented on PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#issuecomment-1893138996 Many people seem not to know about ` 11` adding a comment is just an idea to spread the knowledge you're right that if people grep, they'll need to take care about the comment eager to see feedback from others: is such a comment a benefit or more a problem? -- 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] (MARCHETYPES-82) generate maven.compiler.release property as comment
[
https://issues.apache.org/jira/browse/MARCHETYPES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807061#comment-17807061
]
ASF GitHub Bot commented on MARCHETYPES-82:
---
hboutemy commented on code in PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452971420
##
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
##
@@ -6,6 +6,7 @@
#else
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
Review Comment:
this comment is best placed here because it is activated only when
javaCompilerVersionLocal <= 8, based on effective value at runtime
> generate maven.compiler.release property as comment
> ---
>
> Key: MARCHETYPES-82
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-82
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 1.5
>
>
> if JDK 11+ is used to compile, it's better to define maven.compiler.release
> instead of maven.compiler.source/target
> we currently generate for Java 8, so we don't really know if the compiler
> used support release parameter
> adding a comment is a good first step to help discovery, before benefiting
> from MARCHETYPES-70 when generating against newer JDK
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
hboutemy commented on code in PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452971420
##
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
##
@@ -6,6 +6,7 @@
#else
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
Review Comment:
this comment is best placed here because it is activated only when
javaCompilerVersionLocal <= 8, based on effective value at runtime
--
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
Re: [PR] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
hboutemy commented on code in PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452968733 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml: ## @@ -15,6 +15,7 @@ UTF-8 1.7 1.7 + Review Comment: no, this one is a unit test with value defined in command line: user can decide to generate with forced 1.7 value, that's a good test to keep -- 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] (MARCHETYPES-82) generate maven.compiler.release property as comment
[ https://issues.apache.org/jira/browse/MARCHETYPES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807060#comment-17807060 ] ASF GitHub Bot commented on MARCHETYPES-82: --- hboutemy commented on code in PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452968733 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml: ## @@ -15,6 +15,7 @@ UTF-8 1.7 1.7 + Review Comment: no, this one is a unit test with value defined in command line: user can decide to generate with forced 1.7 value, that's a good test to keep > generate maven.compiler.release property as comment > --- > > Key: MARCHETYPES-82 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-82 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > if JDK 11+ is used to compile, it's better to define maven.compiler.release > instead of maven.compiler.source/target > we currently generate for Java 8, so we don't really know if the compiler > used support release parameter > adding a comment is a good first step to help discovery, before benefiting > from MARCHETYPES-70 when generating against newer JDK -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[ https://issues.apache.org/jira/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened MCOMPILER-97: --- Reopened per Basil's comment > META-INF/services/javax.annotation.processing.Processor copied before > compilation and causes error > -- > > Key: MCOMPILER-97 > URL: https://issues.apache.org/jira/browse/MCOMPILER-97 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Ubuntu 8.10, JDK 6. >Reporter: Jesse N. Glick >Priority: Major > Attachments: MCOMPILER-97-workaround.zip, maven-6647998-test.zip > > > It is tricky to compile a Maven module which defines a (269-compliant) > annotation processor. If you write the code for the processor in > src/main/java and register it in src/main/resources, > META-INF/services/javax.annotation.processing.Processor is copied to > target/classes first, and then javac is run. But javac is given > target/classes in -classpath, so it tries to load the processor, which of > course has not been compiled yet - a chicken-and-egg problem. > The most straightforward workaround is to specify > -proc:none in your POM. This will only > work, however, if the module does not use any annotation processors defined > in dependencies. If it does, there may be some other trick involving > -processorpath and Maven variable substitution to insert the dependency > classpath. > Switching the order of resources:resources and compiler:compile would help - > at least a clean build would work - though it could still cause problems in > incremental builds. Better would be for the compiler plugin to pass > -processorpath based on the dependency classpath (i.e. -classpath minus > target/classes) when using -source 1.6 or higher. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806998#comment-17806998 ] Adrian Tarau commented on MNG-7539: --- Maven 3.8.3. That's correct ... "resolve snapshot". Since it is a snapshot, once the first attempt (for the current multi-module project) to resolve a snapshot is successful, the answer should be cached. The current behavior of Maven is to "resolve" a snapshot every time a module has that snapshot dependency. The only thing I'm saying here is that Maven should not attempt to check if the snapshot changed, it should use the same snapshot for any other module under the reactor build. I might be able to capture the output for some open-source projects...I'll come back with an example. > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Major > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.htmlunit:htmlunit from 3.9.0 to 3.10.0 [maven-doxia-sitetools]
dependabot[bot] opened a new pull request, #133: URL: https://github.com/apache/maven-doxia-sitetools/pull/133 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.9.0 to 3.10.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>org.htmlunit:htmlunit's releases. HtmlUnit 3.10.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html;>migration info Chrome/Edge 120, Firefox 120 many fixes for the neko html parser, rewritten script tag content parsing and better comment handling, unknown elements are always moved to the body, and many more core-js tons of fixes and improvements String.includes/startsWith/endsWith no longer throws a TypeError when the first argument is a regex and Symbol.match of that regex has been set to false String.prototype.replaceAll implemented RegExp.dotAll flag implemented Symbol.iterator property is now available on CSSStyleDeclaration/ComputedCSSStyleDeclaration many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.10.0;>full release notes for details about this release. Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri;>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/48587149cb92dc79fb7c78b2ad0c78535b45263b;>4858714 version 3.10.0 https://github.com/HtmlUnit/htmlunit/commit/b997e79f11591af810da00aabe5800ff93b80f24;>b997e79 core-js release https://github.com/HtmlUnit/htmlunit/commit/d7daeefde0022268c4318ea26543767f4f10d3b0;>d7daeef link fixes https://github.com/HtmlUnit/htmlunit/commit/afef30981912417725f4420ea987ab6a26b7a6ce;>afef309 missing file https://github.com/HtmlUnit/htmlunit/commit/747f6443f4cfd3c686dcbd524f3bcd8e1593a67f;>747f644 ups https://github.com/HtmlUnit/htmlunit/commit/c7bfb7932a865af8a84f79a885c83d4222844753;>c7bfb79 use released versions https://github.com/HtmlUnit/htmlunit/commit/a68d16b3cf6c5bbb66ec97e66dfe45ef4cc86274;>a68d16b change timeout https://github.com/HtmlUnit/htmlunit/commit/b33447a0a42d4bdff9965e020730cab742da9ded;>b33447a fix https://github.com/HtmlUnit/htmlunit/commit/fb98a83118f05888982f4b6ec6da83a569d855f8;>fb98a83 fix tests for the new webClient setup https://github.com/HtmlUnit/htmlunit/commit/36bd5639609cf97c3eb000261beecd404b5c1b60;>36bd563 improve the code check for performance Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.9.0...3.10.0;>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 - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service,
[jira] [Commented] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806983#comment-17806983
]
Filipe Roque commented on SUREFIRE-2233:
I messed up copying to jira. I have updated the description.
the relevant section:
{code:java}
[WARNING] ForkStarter IOException: Unable to create file for report:
/home/froque/workspace/testes/long-filenames/target/surefire-reports/package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.txt
(File name too long). See the dump file
/home/froque/workspace/testes/long-filenames/target/surefire-reports/2024-01-15T22-47-50_794-jvmRun1.dumpstream
{code}
> Unable to create file for report (File name too long)
> --
>
> Key: SUREFIRE-2233
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2233
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.5
> Environment: Linux with encripted home using ecryptfs
>Reporter: Filipe Roque
>Priority: Major
>
> surefire tries to create report files where the filename includes the package.
> On Linux with eCryptfs, it easily fails with _File name too long_ ([What is
> the maximum allowed filename (and folder) size with
> eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
> without failing the maven build.
>
> * Should this error fail the build ?
> * What is the solution for this, besides shorter packages and file names, or
> non encrypted file systems ?
> ** Maybe create sub directories under target/surefire-reports matching the
> packages
> ** shorten the filename like logback
> ([https://logback.qos.ch/manual/layouts.html#conversionWord])
>
> *pom.xml*
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> org.example
> long-filenames
> 1.0-SNAPSHOT
>
>21
>21
>UTF-8
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.10.1
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.2.5
>
>
>
>
> {code}
> {*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
>
> {code:java}
> package
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
> import org.junit.jupiter.api.Assertions;
> import org.junit.jupiter.api.Test;
> public class
> TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
> @Test
> public void test() {
>Assertions.assertTrue(true);
> }
> }
> {code}
>
>
>
>
> {code:java}
> ❯ /opt/maven/apache-maven-3.9.5/bin/mvn clean test
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:long-filenames
> >-
> [INFO] Building long-filenames 1.0-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
> [INFO] Deleting /home/froque/workspace/testes/long-filenames/target
> [INFO]
> [INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
> [INFO] Copying 0 resource from src/main/resources to target/classes
> [INFO]
> [INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- resources:3.3.1:testResources (default-testResources) @
> long-filenames ---
> [INFO] skip non existing resourceDirectory
> /home/froque/workspace/testes/long-filenames/src/test/resources
> [INFO]
> [INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
> ---
> [INFO] Changes detected - recompiling the module! :source
> [INFO] Compiling 1 source file with javac [debug target 21] to
> target/test-classes
> [INFO]
> [INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
> [WARNING] ForkStarter IOException: Unable to create file for report:
>
[jira] [Updated] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Roque updated SUREFIRE-2233:
---
Description:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
([https://logback.qos.ch/manual/layouts.html#conversionWord])
*pom.xml*
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
org.example
long-filenames
1.0-SNAPSHOT
21
21
UTF-8
org.junit.jupiter
junit-jupiter-api
5.10.1
test
org.apache.maven.plugins
maven-surefire-plugin
3.2.5
{code}
{*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
{code:java}
package
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
public class
TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
@Test
public void test() {
Assertions.assertTrue(true);
}
}
{code}
{code:java}
❯ /opt/maven/apache-maven-3.9.5/bin/mvn clean test
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:long-filenames >-
[INFO] Building long-filenames 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
[INFO] Deleting /home/froque/workspace/testes/long-filenames/target
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @
long-filenames ---
[INFO] skip non existing resourceDirectory
/home/froque/workspace/testes/long-filenames/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 1 source file with javac [debug target 21] to
target/test-classes
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[WARNING] ForkStarter IOException: Unable to create file for report:
/home/froque/workspace/testes/long-filenames/target/surefire-reports/package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.txt
(File name too long). See the dump file
/home/froque/workspace/testes/long-filenames/target/surefire-reports/2024-01-15T22-47-50_794-jvmRun1.dumpstream
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.564 s
[INFO] Finished at: 2024-01-15T22:47:51Z
[INFO]
{code}
was:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806979#comment-17806979 ] Abel Salgado Romero commented on DOXIA-725: --- I don't mean to criticize the amazing work, but it's hard to consume those components. The relationship is non-obvious; for instance, you cannot use automatic bumping, and as shown, when you see incompatibilities the code does not reflect you should be using the same version [https://github.com/apache/maven-doxia-sitetools/blob/5fe4a4c5359e6a23b78f385e15f77767cadaee99/pom.xml#L32-L70.] Maybe a BOM could be published that takes care of the dependencies? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
lprimak commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1892813758 Is this really a lot of impact? Also, doesn't Apache Jenkins have this build-in as well? -- 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
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
kwin commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1892806824 Every multi repo ASF project with inter repo dependencies needs that from time to time. -- 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
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
lprimak commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1892801402 > this causes too much friction I still don't see this friction. Let's look at the actual use case where this is used. The only use case I see is when the Apache project being built depends on another Apache project's SNAPSHOT build. How many instances of this use case actually exist? My bet is not many. I still see the impact of this change as very minimal. Am I missing something glaring here? 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452757436 ## pom.xml: ## @@ -403,6 +403,26 @@ under the License. + +enforce-maven.compiler.target-version + + enforce + + + + + maven.compiler.target + (?!1\.).* + The value of property maven.compiler.target must not start with "1.", use for example "8" instead of "1.8"! + + + maven.compiler.source + (?!1\.).* + The value of property maven.compiler.source must not start with "1.", use for example "8" instead of "1.8"! + + + + Review Comment: I removed the enforcement of the property in https://github.com/apache/maven-apache-parent/pull/188/commits/8ab37cef72208e2b9667dbd298a446b16696ec66. ## pom.xml: ## @@ -525,6 +545,17 @@ under the License. + + jdk9ornewer Review Comment: Done in https://github.com/apache/maven-apache-parent/pull/188/commits/8ab37cef72208e2b9667dbd298a446b16696ec66. -- 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
Re: [PR] [MPOM-453] Disable annotation processing by compiler [maven-parent]
kwin commented on PR #157: URL: https://github.com/apache/maven-parent/pull/157#issuecomment-1892766720 I think it is best practice to only enable annotation processors by their fully qualified class name. This is possible by setting https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#annotationProcessors. This should IMHO take precedence (but I haven’t checked) over proc being none. -- 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
Re: [PR] [MPOM-453] Disable annotation processing by compiler [maven-parent]
cstamas commented on PR #157: URL: https://github.com/apache/maven-parent/pull/157#issuecomment-1892757366 With a grain of salt... I'd rather define `compiler.proc=none` property and allow that property to be changed, than this. As if project DOES need annotation processing, and is below Java 21 (see https://bugs.openjdk.org/browse/JDK-8309870) then there is _no way_ to override 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] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806964#comment-17806964
]
Herve Boutemy commented on MPOM-264:
it is in maven-parent
https://github.com/apache/maven-parent/blob/master/pom.xml#L1317
in fact, I expected others to do it before me, and was surprised it had not
been done, I suppose for a reason I did not know :)
one aspect is 1.x vs x, that I finally took time to document why it is
reasonable in MPOM-449
but you're right, it's something that should be done at ASF level, not Maven
only
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
michael-o commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452690304 ## pom.xml: ## @@ -525,6 +545,17 @@ under the License. + + jdk9ornewer Review Comment: Make is simple: `jdk9+`? -- 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
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
michael-o commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452689833 ## pom.xml: ## @@ -403,6 +403,26 @@ under the License. + +enforce-maven.compiler.target-version + + enforce + + + + + maven.compiler.target + (?!1\.).* + The value of property maven.compiler.target must not start with "1.", use for example "8" instead of "1.8"! + + + maven.compiler.source + (?!1\.).* + The value of property maven.compiler.source must not start with "1.", use for example "8" instead of "1.8"! + + + + Review Comment: I'll let it fail implicitly... -- 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
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
slawekjaranowski commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452687769 ## pom.xml: ## @@ -403,6 +403,26 @@ under the License. + +enforce-maven.compiler.target-version + + enforce + + + + + maven.compiler.target + (?!1\.).* + The value of property maven.compiler.target must not start with "1.", use for example "8" instead of "1.8"! + + + maven.compiler.source + (?!1\.).* + The value of property maven.compiler.source must not start with "1.", use for example "8" instead of "1.8"! + + + + Review Comment: I would like to not add next execution, simply if user has wrong value build will fail. -- 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
[PR] Bump org.htmlunit:htmlunit from 3.9.0 to 3.10.0 [maven-surefire]
dependabot[bot] opened a new pull request, #717: URL: https://github.com/apache/maven-surefire/pull/717 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.9.0 to 3.10.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>org.htmlunit:htmlunit's releases. HtmlUnit 3.10.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html;>migration info Chrome/Edge 120, Firefox 120 many fixes for the neko html parser, rewritten script tag content parsing and better comment handling, unknown elements are always moved to the body, and many more core-js tons of fixes and improvements String.includes/startsWith/endsWith no longer throws a TypeError when the first argument is a regex and Symbol.match of that regex has been set to false String.prototype.replaceAll implemented RegExp.dotAll flag implemented Symbol.iterator property is now available on CSSStyleDeclaration/ComputedCSSStyleDeclaration many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.10.0;>full release notes for details about this release. Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri;>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/48587149cb92dc79fb7c78b2ad0c78535b45263b;>4858714 version 3.10.0 https://github.com/HtmlUnit/htmlunit/commit/b997e79f11591af810da00aabe5800ff93b80f24;>b997e79 core-js release https://github.com/HtmlUnit/htmlunit/commit/d7daeefde0022268c4318ea26543767f4f10d3b0;>d7daeef link fixes https://github.com/HtmlUnit/htmlunit/commit/afef30981912417725f4420ea987ab6a26b7a6ce;>afef309 missing file https://github.com/HtmlUnit/htmlunit/commit/747f6443f4cfd3c686dcbd524f3bcd8e1593a67f;>747f644 ups https://github.com/HtmlUnit/htmlunit/commit/c7bfb7932a865af8a84f79a885c83d4222844753;>c7bfb79 use released versions https://github.com/HtmlUnit/htmlunit/commit/a68d16b3cf6c5bbb66ec97e66dfe45ef4cc86274;>a68d16b change timeout https://github.com/HtmlUnit/htmlunit/commit/b33447a0a42d4bdff9965e020730cab742da9ded;>b33447a fix https://github.com/HtmlUnit/htmlunit/commit/fb98a83118f05888982f4b6ec6da83a569d855f8;>fb98a83 fix tests for the new webClient setup https://github.com/HtmlUnit/htmlunit/commit/36bd5639609cf97c3eb000261beecd404b5c1b60;>36bd563 improve the code check for performance Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.9.0...3.10.0;>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 - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please
[jira] [Commented] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806942#comment-17806942
]
Michael Osipov commented on SUREFIRE-2233:
--
Where is the failure?
> Unable to create file for report (File name too long)
> --
>
> Key: SUREFIRE-2233
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2233
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.5
> Environment: Linux with encripted home using ecryptfs
>Reporter: Filipe Roque
>Priority: Major
>
> surefire tries to create report files where the filename includes the package.
> On Linux with eCryptfs, it easily fails with _File name too long_ ([What is
> the maximum allowed filename (and folder) size with
> eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
> without failing the maven build.
>
> * Should this error fail the build ?
> * What is the solution for this, besides shorter packages and file names, or
> non encrypted file systems ?
> ** Maybe create sub directories under target/surefire-reports matching the
> packages
> ** shorten the filename like logback
> ([https://logback.qos.ch/manual/layouts.html#conversionWord])
>
> *pom.xml*
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> org.example
> long-filenames
> 1.0-SNAPSHOT
>
>21
>21
>UTF-8
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.10.1
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.2.5
>
>
>
>
> {code}
> {*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
>
> {code:java}
> package
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
> import org.junit.jupiter.api.Assertions;
> import org.junit.jupiter.api.Test;
> public class
> TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
> @Test
> public void test() {
>Assertions.assertTrue(true);
> }
> }
> {code}
>
>
>
>
> {code:java}
> /opt/maven/apache-maven-3.9.5/bin/mvn clean test
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:long-filenames
> >-
> [INFO] Building long-filenames 1.0-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
> [INFO]
> [INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
> [INFO] Copying 0 resource from src/main/resources to target/classes
> [INFO]
> [INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- resources:3.3.1:testResources (default-testResources) @
> long-filenames ---
> [INFO] skip non existing resourceDirectory
> /home/froque/workspace/testes/long-filenames/src/test/resources
> [INFO]
> [INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
> ---
> [INFO] Changes detected - recompiling the module! :source
> [INFO] Compiling 1 source file with javac [debug target 21] to
> target/test-classes
> [INFO]
> [INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
> s -- in
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.269 s
> [INFO] Finished at: 2024-01-15T17:14:48Z
> [INFO]
>
[PR] [MPOM-365] Remove no longer used ".maven-apache-parent.marker" file [maven-apache-parent]
kwin opened a new pull request, #189: URL: https://github.com/apache/maven-apache-parent/pull/189 This has been introduced in MPOM-255 for enabling a profile only when building the ASF parent itself. -- 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] (MPOM-255) Enforce local property "project.build.outputTimestamp" for reproducible builds
[ https://issues.apache.org/jira/browse/MPOM-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806939#comment-17806939 ] Konrad Windszus commented on MPOM-255: -- FTR: change has been reverted in MPOM-265. > Enforce local property "project.build.outputTimestamp" for reproducible builds > -- > > Key: MPOM-255 > URL: https://issues.apache.org/jira/browse/MPOM-255 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Assignee: Michael Osipov >Priority: Major > Fix For: ASF-24 > > > In case the release's root pom.xml doesn't overwrite > "project.build.outputTimestamp" it takes the value from > [https://github.com/apache/maven-apache-parent/blob/4813409e6a1ecfea11c8eb22a5f0443f790f1454/pom.xml#L95.] > Instead of the fallback an enforcer rule should be added to require a > property "project.build.outputTimestamp" to be set in the right format for > reproducible builds to work > ([https://maven.apache.org/guides/mini/guide-reproducible-builds.html#how-do-i-configure-my-maven-build]) > for every pom.xml locally. > Only that way the timestamps are automatically adjusted with each release > (https://issues.apache.org/jira/browse/MRELEASE-1029) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPOM-450) Prevent the SCM elements from being inherited
[
https://issues.apache.org/jira/browse/MPOM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806938#comment-17806938
]
Konrad Windszus commented on MPOM-450:
--
The {{scm}} element cannot be set within a profile
(https://maven.apache.org/pom.html#Profiles).
> Prevent the SCM elements from being inherited
> -
>
> Key: MPOM-450
> URL: https://issues.apache.org/jira/browse/MPOM-450
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Affects Versions: ASF-31
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the SCM elements are not encapsulated in a profile, i.e. they are
> automatically inherited by all derived projects. As those never share
> anything with the SCM URLs of the ASF parent it would make sense to only
> conditionally set those SCM elements (in a profile).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MPOM-450) Prevent the SCM elements from being inherited
[ https://issues.apache.org/jira/browse/MPOM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed MPOM-450. Resolution: Won't Fix > Prevent the SCM elements from being inherited > - > > Key: MPOM-450 > URL: https://issues.apache.org/jira/browse/MPOM-450 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-31 >Reporter: Konrad Windszus >Priority: Major > > Currently the SCM elements are not encapsulated in a profile, i.e. they are > automatically inherited by all derived projects. As those never share > anything with the SCM URLs of the ASF parent it would make sense to only > conditionally set those SCM elements (in a profile). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-464) JDK transport bug
Tamas Cservenak created MRESOLVER-464: - Summary: JDK transport bug Key: MRESOLVER-464 URL: https://issues.apache.org/jira/browse/MRESOLVER-464 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-7 JDK transport seems can be plagued by https://bugs.openjdk.org/browse/JDK-8225647 Try to do something about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MNG-8019 streamline central update policy [maven]
kwin commented on PR #1381: URL: https://github.com/apache/maven/pull/1381#issuecomment-1892625986 For Maven 4 both are already at the default (=daily), being applied in https://github.com/apache/maven/commit/fb612f5dbc89d8e268bc3581e538c392c1fff788. So this is basically the backport of MNG-6112. -- 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-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806935#comment-17806935
]
ASF GitHub Bot commented on MNG-8019:
-
kwin commented on PR #1381:
URL: https://github.com/apache/maven/pull/1381#issuecomment-1892625986
For Maven 4 both are already at the default (=daily), being applied in
https://github.com/apache/maven/commit/fb612f5dbc89d8e268bc3581e538c392c1fff788.
So this is basically the backport of MNG-6112.
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452661893
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
javac 17 still supports 7, only javac21 only supports 8+.
--
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
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452661893
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
javac 17 still supports 7, only javac 21 only supports 8+.
--
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
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452660696
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
yes it is: back to 5 if javac 8 is used,
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html#BHCDIFEE
--
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
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
slawekjaranowski commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452659630
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
I'm not sure if `7` is supported maybe it is time to switch it to `8`
--
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-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806931#comment-17806931 ] Konrad Windszus commented on DOXIA-725: --- It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why cannot stick to Doxia M8 for the moment? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806931#comment-17806931 ] Konrad Windszus edited comment on DOXIA-725 at 1/15/24 6:14 PM: It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why you cannot stick to Doxia M8 for the moment? was (Author: kwin): It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why cannot stick to Doxia M8 for the moment? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452651203
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
should we enforce with
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html that this
property value does no longer start with "1."?
--
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-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806926#comment-17806926 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks, wouldn't it make sense to merge all in the same repo under the same parent? Now that we have the chance to make breaking changes? > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806925#comment-17806925
]
David M. Lloyd commented on MRESOLVER-336:
--
There are many thousand artifacts already in the wild using qualifiers, both
standard and custom, so I think that ship has sailed. But in any event, the
version syntax must be well-defined for all allowed cases, otherwise it's not
really a syntax. The behavior should be completely predictable.
Many of these bug reports came from me trying to determine or establish the
"true" syntactic rules of Maven versions. The code disagrees with itself every
place it is implemented, and the developers also seem to disagree with one
another on what these rules should be. But based on feedback from developers on
this and other issues, I think the most generally-accepted rules when
considering spec intent, existing usage, and existing code are as follows:
* Versions should be compared by segment, from left to right, where each
segment is defined and ordered as follows (from earliest to latest):
** The qualifier "alpha" == "a" (but only when "a" is immediately followed by
a number)
** The qualifier "beta" == "b" (but only when "b" is immediately followed by a
number)
** The qualifier "milestone" = "m" (but only when "m" is immediately followed
by a number)
** The qualifier "rc" == "cr"
** The qualifier "snapshot"
** The empty string == the number zero == "ga" == "final" == "release" (I call
these "zero segments" down below)
** The qualifier "sp"
** Any "custom" qualifier (i.e. non-empty letter sequence) sorted
lexicographically per {{ROOT}} locale, ascending
** Any positive integer sorted numerically ascending
* Segments can be explicitly separated by a single {{.}} (dot) or {{-}}
(hyphen) (one proposal also included {{_}} (underscore) as a separator)
* All qualifiers (not just custom qualifiers) are interpreted as being
case-insensitive in terms of the {{ROOT}} locale (that is, "FINAL" is equal to
"final", not "fınal")
* A zero-width segment separator also exists between any two segments when one
of the two segments is a number of any kind (including 0) and the other is a
alphabetical qualifier of any kind (including special qualifiers)
* Finally, any version can be considered to have an infinite number of
invisible *trailing* "zero" segments, for the purposes of comparison (in other
words, "1" == "1.0.0.0.0.0.0.0.0")
According to the above rules, I think that the example version I gave above
"0.0.0.ga.ga.foo" should *not* be equal to "foo" exactly as "0.0.1" should not
be equal to "1". It *should* be equal to "0.0.0.0.0.foo". The issue itself is
due to the {{ga}} qualifier being equal to zero *sometimes* but not other
times. This inconsistency is the problem and should be fixed as described above.
I don't think it is realistic to get all or even most Java devs to agree on one
version {*}scheme{*}. However I do think it is not only realistic but
*critical* that we all agree on one version {*}syntax{*}. And, I think the
above is it, more or less, since it seems to eliminate most (maybe all) of the
problem cases that I could find in existing artifacts.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to
[jira] [Updated] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Roque updated SUREFIRE-2233:
---
Description:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
([https://logback.qos.ch/manual/layouts.html#conversionWord])
*pom.xml*
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
org.example
long-filenames
1.0-SNAPSHOT
21
21
UTF-8
org.junit.jupiter
junit-jupiter-api
5.10.1
test
org.apache.maven.plugins
maven-surefire-plugin
3.2.5
{code}
{*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
{code:java}
package
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
public class
TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
@Test
public void test() {
Assertions.assertTrue(true);
}
}
{code}
{code:java}
/opt/maven/apache-maven-3.9.5/bin/mvn clean test
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:long-filenames >-
[INFO] Building long-filenames 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @
long-filenames ---
[INFO] skip non existing resourceDirectory
/home/froque/workspace/testes/long-filenames/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 1 source file with javac [debug target 21] to
target/test-classes
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 s
-- in
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.269 s
[INFO] Finished at: 2024-01-15T17:14:48Z
[INFO]
{code}
was:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
(https://logback.qos.ch/manual/layouts.html#conversionWord)
[jira] [Created] (SUREFIRE-2233) Unable to create file for report (File name too long)
Filipe Roque created SUREFIRE-2233:
--
Summary: Unable to create file for report (File name too long)
Key: SUREFIRE-2233
URL: https://issues.apache.org/jira/browse/SUREFIRE-2233
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.2.5
Environment: Linux with encripted home using ecryptfs
Reporter: Filipe Roque
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
(https://logback.qos.ch/manual/layouts.html#conversionWord)
*pom.xml*
{code:java}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
org.example
long-filenames
1.0-SNAPSHOT
21
21
UTF-8
org.junit.jupiter
junit-jupiter-api
5.10.1
test
org.apache.maven.plugins
maven-surefire-plugin
3.2.5
{code}
{*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{*}
{code:java}
{code}
*package
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
public class
TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName \{
@Test
public void test() {
Assertions.assertTrue(true);
}
}*
{code:java}
{code}
*❯ /opt/maven/apache-maven-3.9.5/bin/mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:long-filenames >-
[INFO] Building long-filenames 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
[INFO] Deleting /home/froque/workspace/testes/long-filenames/target
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @
long-filenames ---
[INFO] skip non existing resourceDirectory
/home/froque/workspace/testes/long-filenames/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 1 source file with javac [debug target 21] to
target/test-classes
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[WARNING] ForkStarter IOException: Unable to create file for report:
/home/froque/workspace/testes/long-filenames/target/surefire-reports/package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.txt
(File name too long). See the dump file
/home/froque/workspace/testes/long-filenames/target/surefire-reports/2024-01-15T16-58-22_070-jvmRun1.dumpstream
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ long-filenames ---
[INFO] Building jar:
/home/froque/workspace/testes/long-filenames/target/long-filenames-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.523 s
[INFO] Finished at: 2024-01-15T16:58:22Z
[INFO]
*
--
This message was
Re: [PR] Publish Maven 4.0.0-alpha-12 [maven-site]
gnodet merged PR #487: URL: https://github.com/apache/maven-site/pull/487 -- 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
[PR] Publish Maven 4.0.0-alpha-12 [maven-site]
gnodet opened a new pull request, #487: URL: https://github.com/apache/maven-site/pull/487 (no comment) -- 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-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806912#comment-17806912
]
ASF GitHub Bot commented on MNG-8019:
-
cstamas commented on PR #1381:
URL: https://github.com/apache/maven/pull/1381#issuecomment-1892507041
@gnodet was working on this or similar change not so long time ago...
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] MNG-8019 streamline central update policy [maven]
cstamas commented on PR #1381: URL: https://github.com/apache/maven/pull/1381#issuecomment-1892507041 @gnodet was working on this or similar change not so long time ago... -- 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
Re: [PR] Simplify graph [maven]
gnodet merged PR #1380: URL: https://github.com/apache/maven/pull/1380 -- 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] (MNG-8020) Support new Resolve 2.0 split policies
Tamas Cservenak created MNG-8020: Summary: Support new Resolve 2.0 split policies Key: MNG-8020 URL: https://issues.apache.org/jira/browse/MNG-8020 Project: Maven Issue Type: Task Affects Versions: 4.0.x-candidate Reporter: Tamas Cservenak The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8020) Support new Resolve 2.0 split policies
[ https://issues.apache.org/jira/browse/MNG-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8020: - Description: The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this. Current Maven4 code works in same way as Maven3 does, as Resolver 2.0 handles this (policy Maven sets is applied to both). (was: The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this.) > Support new Resolve 2.0 split policies > -- > > Key: MNG-8020 > URL: https://issues.apache.org/jira/browse/MNG-8020 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.x-candidate >Reporter: Tamas Cservenak >Priority: Major > > The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. > But, this requires model and many other changes, so consider when to do this. > Current Maven4 code works in same way as Maven3 does, as Resolver 2.0 handles > this (policy Maven sets is applied to both). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[
https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806909#comment-17806909
]
Tamas Cservenak edited comment on MNG-7539 at 1/15/24 4:46 PM:
---
What Maven version you use? When you say "validate snapshot" you mean "resolve
snapshot"? You say that one reactor build can download two distinct
(timestamped) versions of same -SNAPSHOT dependency? Can you provide a
reproducer for this? I can imagine this under very uncommon build settings,
like using {{-U}} per each invocation and having new snapshots deployed (but
even then, one artifact is "refreshed" only once).
was (Author: cstamas):
What Maven version you use? When you say "validate snapshot" you mean "resolve
snapshot"? You say that one reactor build can download two distinct
(timestamped) versions of same -SNAPSHOT dependency? Can you provide a
reproducer for this?
> Validate/Download SNAPSHOT dependencies once
>
>
> Key: MNG-7539
> URL: https://issues.apache.org/jira/browse/MNG-7539
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Adrian Tarau
>Priority: Major
>
> Building an unreleased multi-module project (30-40 modules) that depends on
> various other unreleased modules puts significant pressure on the Maven
> Repository (a local Nexus instance), and artifact resolution could slow down
> the build 2x-3x.
> I do acknowledge that it is the job of the repository to cache and serve
> those responses fast, and for some reason, sometimes it slows down without an
> apparent reason.
> However, the whole build process will be faster if Maven validates a SNAPSHOT
> once for multi-module (when the dependency is reached the first time) and
> then use that version. Even if Maven Repository is relative fast, there is
> still network traffic done. Outside the fact that it should not be done, it
> might also introduce flaky behaviors:
> * one module downloads a version of artifact A, works with it, and
> everything is fine
> * 10 minutes later, another module needs artifact A and gets a newer
> version, which has some issues, and various (test) failures will be raised
> For consistency, on a multi-module build, all modules should _see_ the same
> version of a SNAPSHOT artifact. It will be faster, and it will be consistent
> (which is very important).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806909#comment-17806909 ] Tamas Cservenak commented on MNG-7539: -- What Maven version you use? When you say "validate snapshot" you mean "resolve snapshot"? You say that one reactor build can download two distinct (timestamped) versions of same -SNAPSHOT dependency? Can you provide a reproducer for this? > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Major > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#issuecomment-1892476653 FTR: This is a simplified version of #48 which was declined back then. Nowadays the profile is even used within Maven Parent: https://issues.apache.org/jira/browse/MPOM-447 -- 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
[PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin opened a new pull request, #188: URL: https://github.com/apache/maven-apache-parent/pull/188 (no comment) -- 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] [Assigned] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MPOM-264:
Assignee: Konrad Windszus
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-217) Allow extra "sources" for Artifact decoration
[ https://issues.apache.org/jira/browse/MRESOLVER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-217: -- Fix Version/s: (was: 2.0.0) > Allow extra "sources" for Artifact decoration > - > > Key: MRESOLVER-217 > URL: https://issues.apache.org/jira/browse/MRESOLVER-217 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > For start, a simple API that would "enhance" Artifact instances from it (like > populating artifact properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-233) Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
[
https://issues.apache.org/jira/browse/MRESOLVER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806871#comment-17806871
]
Tamas Cservenak commented on MRESOLVER-233:
---
I disagree with this change (the original PR): the type of the new instance
some methods return contextually depend on current type. For example
SubArtifact.setVersion should NOT return (unmodified) subArtifact with modified
mainArtifact, as in that case we do not talk about subArtifact anymore, but
completely different GAVCE.
In essence, these types are ONLY to help you construct coordinates, it is _very
very rare_ when actual type is needed (only example I know is
RelocatedArtifact, that is cast in core only to get message).
> Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
> --
>
> Key: MRESOLVER-233
> URL: https://issues.apache.org/jira/browse/MRESOLVER-233
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 2.0.0
>
>
> This method has two issues:
> * It lacks abstraction that it relies on a subtype which should be unknown
> here
> * with an abstract method every derived type can properly return again a
> derived type instead of having {{DefaultArtifact}} which loses details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-233) Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
[
https://issues.apache.org/jira/browse/MRESOLVER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-233:
--
Fix Version/s: (was: 2.0.0)
> Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
> --
>
> Key: MRESOLVER-233
> URL: https://issues.apache.org/jira/browse/MRESOLVER-233
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: Michael Osipov
>Priority: Major
>
> This method has two issues:
> * It lacks abstraction that it relies on a subtype which should be unknown
> here
> * with an abstract method every derived type can properly return again a
> derived type instead of having {{DefaultArtifact}} which loses details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8017:
-
Fix Version/s: 4.0.0-alpha-13
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-12
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.0.0-alpha-13
>
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8017:
-
Affects Version/s: 4.0.0-alpha-12
(was: 4.0.0-alpha-13)
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-12
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Assignee: Guillaume Nodet
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8017:
Assignee: Guillaume Nodet
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-13
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Assignee: Guillaume Nodet
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806853#comment-17806853
]
ASF GitHub Bot commented on MRESOLVER-264:
--
cstamas opened a new pull request, #405:
URL: https://github.com/apache/maven-resolver/pull/405
Make file lock factory and file-hgav mapper the default.
---
https://issues.apache.org/jira/browse/MRESOLVER-264
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-264:
--
Fix Version/s: 2.0.0-alpha-7
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-243) Get rid of pre-Java 5 constructs that are cryptic
[ https://issues.apache.org/jira/browse/MRESOLVER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-243. - Fix Version/s: (was: 2.0.0) Resolution: Not A Problem > Get rid of pre-Java 5 constructs that are cryptic > - > > Key: MRESOLVER-243 > URL: https://issues.apache.org/jira/browse/MRESOLVER-243 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > There are in some places (ChecksumPolicy kind was already fixed) still in > codebase, that use pre-enum constructs. Kill them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
cstamas opened a new pull request, #405: URL: https://github.com/apache/maven-resolver/pull/405 Make file lock factory and file-hgav mapper the default. --- https://issues.apache.org/jira/browse/MRESOLVER-264 -- 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] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-336:
--
Fix Version/s: (was: 2.0.0)
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reopened MRESOLVER-336:
---
Reopening, to give some time for reporter to respond.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-336.
-
Resolution: Won't Fix
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806848#comment-17806848
]
Tamas Cservenak edited comment on MRESOLVER-336 at 1/15/24 2:24 PM:
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, but ideally
avoid them.
was (Author: cstamas):
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, ideally avoid
them.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806848#comment-17806848
]
Tamas Cservenak edited comment on MRESOLVER-336 at 1/15/24 2:23 PM:
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, ideally avoid
them.
was (Author: cstamas):
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-336:
-
Assignee: Tamas Cservenak
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806848#comment-17806848
]
Tamas Cservenak commented on MRESOLVER-336:
---
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806834#comment-17806834 ] Elliotte Rusty Harold commented on MPMD-391: I want less logs, not more. "Running PMD version 6.55.0 to target/pmd.xml" is not info the developer needs or cares about. It is not actionable. Neither is the skin. Neither is the version of the plugin. These are at most, debugging info for plugin developers. They should not be shown to normal end users who just want to build their project. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-336:
--
Component/s: Resolver
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806796#comment-17806796
]
Guillaume Nodet commented on MNG-8017:
--
The problem is that the JLine bundle does not include the native libraries
anymore. I've raised [https://github.com/jline/jline3/issues/927]
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-13
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806788#comment-17806788
]
Guillaume Nodet commented on MNG-8017:
--
There's another hidden problem I think.
JLine is supposed to support natively the FreeBSD / x86_64, so if JLine ends up
using the {{exec}} provider, it means the \{{native}} one failed to load, which
is unexpected.
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-13
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8014] Workaround for deadlocks in model building [maven]
gnodet merged PR #1376: URL: https://github.com/apache/maven/pull/1376 -- 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-8014) Maven concurrent model builder deadlocks
[ https://issues.apache.org/jira/browse/MNG-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806778#comment-17806778 ] ASF GitHub Bot commented on MNG-8014: - gnodet merged PR #1376: URL: https://github.com/apache/maven/pull/1376 > Maven concurrent model builder deadlocks > > > Key: MNG-8014 > URL: https://issues.apache.org/jira/browse/MNG-8014 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-10 >Reporter: Guillaume Nodet >Priority: Major > > Building [https://github.com/gnodet/quarkus/tree/maven-deadlock] with Maven > 4.0.0-alpha-12 deadlocks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806770#comment-17806770
]
ASF GitHub Bot commented on MNG-8019:
-
kwin opened a new pull request, #1381:
URL: https://github.com/apache/maven/pull/1381
(no comment)
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] MNG-8019 streamline central update policy [maven]
kwin opened a new pull request, #1381: URL: https://github.com/apache/maven/pull/1381 (no comment) -- 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-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8019:
-
Summary: Streamline update policy of pluginRepository/repository of Maven
Central in Super POM (was: Streamline update policy of
pluginRepository/repository of Maven Central)
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central
Konrad Windszus created MNG-8019:
Summary: Streamline update policy of pluginRepository/repository
of Maven Central
Key: MNG-8019
URL: https://issues.apache.org/jira/browse/MNG-8019
Project: Maven
Issue Type: Improvement
Components: Artifacts and Repositories
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: 3.9.x-candidate
The update policy is set to {{never}} for the Maven Central
{{pluginRepository}}
(https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
while it is the default (= {{daily}}) for the regular repository.
Although it would be nice to set both to {{never}} this does not work with
Resolver 1.x as that treats metadata and artifacts the same (but in fact
metadata is constantly changing even for release repositories like Maven
Central). This situation should improve with Resolver 2.x (Maven 4)
(https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-334:
-
Assignee: Tamas Cservenak
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806765#comment-17806765
]
ASF GitHub Bot commented on MRESOLVER-334:
--
cstamas opened a new pull request, #486:
URL: https://github.com/apache/maven-site/pull/486
The spec page had some edge case issues that were actually spec errors (as
implementations were rightfully not doing this same).
Note: generic version in resolver is authoritative in Maven4 as
maven-artifact versions are to be killed off.
---
https://issues.apache.org/jira/browse/MRESOLVER-334
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MRESOLVER-334] Align spec with implementation [maven-site]
cstamas opened a new pull request, #486: URL: https://github.com/apache/maven-site/pull/486 The spec page had some edge case issues that were actually spec errors (as implementations were rightfully not doing this same). Note: generic version in resolver is authoritative in Maven4 as maven-artifact versions are to be killed off. --- https://issues.apache.org/jira/browse/MRESOLVER-334 -- 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] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806764#comment-17806764
]
ASF GitHub Bot commented on MSHARED-1351:
-
abelsromero commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452265164
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
Are you suggesting to put "." in the message?
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
abelsromero commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452265164
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
Are you suggesting to put "." in the message?
--
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-243) Get rid of pre-Java 5 constructs that are cryptic
[ https://issues.apache.org/jira/browse/MRESOLVER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806760#comment-17806760 ] Tamas Cservenak commented on MRESOLVER-243: --- Conflict resolver change is quite confined, while DependencyNode is straight forward. The other uses were fixed with new checksum api... so unsure do we really want to do anything in here... > Get rid of pre-Java 5 constructs that are cryptic > - > > Key: MRESOLVER-243 > URL: https://issues.apache.org/jira/browse/MRESOLVER-243 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > There are in some places (ChecksumPolicy kind was already fixed) still in > codebase, that use pre-enum constructs. Kill them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-463. - Resolution: Fixed > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-463: - Assignee: Romain Manni-Bucau > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806757#comment-17806757 ] ASF GitHub Bot commented on MRESOLVER-463: -- cstamas merged PR #404: URL: https://github.com/apache/maven-resolver/pull/404 > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-463] sort checksum summary file per path and not checksum to be human friendly [maven-resolver]
cstamas merged PR #404: URL: https://github.com/apache/maven-resolver/pull/404 -- 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] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806750#comment-17806750
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452232812
##
src/main/java/org/apache/maven/shared/filtering/ConsoleHolder.java:
##
@@ -0,0 +1,88 @@
+/*
+ * 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.
+ */
+package org.apache.maven.shared.filtering;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.PrintStream;
+
+/**
+ * Helping class to capture console input and output for tests.
+ *
+ * @author abelsromero
+ * @since 3.3.2
+ */
+class ConsoleHolder {
Review Comment:
better in `src/test/java` than `src/main/java`
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452232812
##
src/main/java/org/apache/maven/shared/filtering/ConsoleHolder.java:
##
@@ -0,0 +1,88 @@
+/*
+ * 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.
+ */
+package org.apache.maven.shared.filtering;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.PrintStream;
+
+/**
+ * Helping class to capture console input and output for tests.
+ *
+ * @author abelsromero
+ * @since 3.3.2
+ */
+class ConsoleHolder {
Review Comment:
better in `src/test/java` than `src/main/java`
--
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
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452231849
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
classical value is `.`, isn't 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] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806748#comment-17806748
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452231849
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
classical value is `.`, isn't it?
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-723) Optionally expose document location in Sink
[
https://issues.apache.org/jira/browse/DOXIA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806722#comment-17806722
]
ASF GitHub Bot commented on DOXIA-723:
--
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452152264
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * 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.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
This is used in `Sink` (not in `Parser`), therefore the only option would be
to move to `AbstractSink`.
> Optionally expose document location in Sink
> ---
>
> Key: DOXIA-723
> URL: https://issues.apache.org/jira/browse/DOXIA-723
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to http://www.saxproject.org/apidoc/org/xml/sax/Locator.html the Sink
> API should provide means to figure out the document location. This should be
> available whenever the Sink events are emitted from parsing a file.
> The locator should expose file name, line number and column number.
> This can be used enhance warning/errors as otherwise it is very hard to
> figure out the root cause of messages like
> https://github.com/apache/maven-doxia/blob/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/Xhtml5BaseSink.java#L930.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-723) Optionally expose document location in Sink
[
https://issues.apache.org/jira/browse/DOXIA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806721#comment-17806721
]
ASF GitHub Bot commented on DOXIA-723:
--
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452150977
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
Any proposal on how to rename? Sinks are either used from a parser or
manually. Obviously the locator primarily makes sense to the former. But the
whole point of this PR and the related issue is that this should be available
in sinks.
> Optionally expose document location in Sink
> ---
>
> Key: DOXIA-723
> URL: https://issues.apache.org/jira/browse/DOXIA-723
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to http://www.saxproject.org/apidoc/org/xml/sax/Locator.html the Sink
> API should provide means to figure out the document location. This should be
> available whenever the Sink events are emitted from parsing a file.
> The locator should expose file name, line number and column number.
> This can be used enhance warning/errors as otherwise it is very hard to
> figure out the root cause of messages like
> https://github.com/apache/maven-doxia/blob/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/Xhtml5BaseSink.java#L930.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-723] Expose document location in Sink [maven-doxia]
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452152264
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * 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.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
This is used in `Sink` (not in `Parser`), therefore the only option would be
to move to `AbstractSink`.
--
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
Re: [PR] [DOXIA-723] Expose document location in Sink [maven-doxia]
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452150977
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
Any proposal on how to rename? Sinks are either used from a parser or
manually. Obviously the locator primarily makes sense to the former. But the
whole point of this PR and the related issue is that this should be available
in sinks.
--
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
[PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.0 to 4.9.1 [maven-ear-plugin]
dependabot[bot] opened a new pull request, #106: URL: https://github.com/apache/maven-ear-plugin/pull/106 Bumps [org.codehaus.plexus:plexus-archiver](https://github.com/codehaus-plexus/plexus-archiver) from 4.9.0 to 4.9.1. Release notes Sourced from https://github.com/codehaus-plexus/plexus-archiver/releases;>org.codehaus.plexus:plexus-archiver's releases. 4.9.1 New features and improvements https://redirect.github.com/codehaus-plexus/plexus-archiver/issues/311;>#311 - provide fluent setter for usingDefaultExcludes flag in Abstrac… (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/312;>#312) https://github.com/redzi;>@redzi Dependency updates Bump org.codehaus.plexus:plexus from 15 to 16 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/316;>#316) https://github.com/dependabot;>@dependabot Bump com.github.luben:zstd-jni from 1.5.5-10 to 1.5.5-11 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/314;>#314) https://github.com/dependabot;>@dependabot Bump commons-io:commons-io from 2.15.0 to 2.15.1 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/313;>#313) https://github.com/dependabot;>@dependabot Bump org.apache.commons:commons-compress from 1.24.0 to 1.25.0 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/309;>#309) https://github.com/dependabot;>@dependabot Maintenance Reuse plexus-pom action for CI (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/315;>#315) https://github.com/slachiewicz;>@slachiewicz Commits https://github.com/codehaus-plexus/plexus-archiver/commit/fb02b02a78d4adecef4e32f304f9f6d3ab7b9861;>fb02b02 [maven-release-plugin] prepare release plexus-archiver-4.9.1 https://github.com/codehaus-plexus/plexus-archiver/commit/d953f322ccbb38479b04abbde3645f77eafd489a;>d953f32 Bump org.codehaus.plexus:plexus from 15 to 16 https://github.com/codehaus-plexus/plexus-archiver/commit/54c42c20e531b9e642a3c70c215814b5a4d61a3b;>54c42c2 Bump com.github.luben:zstd-jni from 1.5.5-10 to 1.5.5-11 https://github.com/codehaus-plexus/plexus-archiver/commit/cb4b6668a8dde2d04aaac37e8265b3e009cb2ca9;>cb4b666 Reuse plexus-pom action for CI https://github.com/codehaus-plexus/plexus-archiver/commit/20cf65421aacbb133a9fe228dbe9fc06000def7a;>20cf654 Bump commons-io:commons-io from 2.15.0 to 2.15.1 https://github.com/codehaus-plexus/plexus-archiver/commit/fca25e56461394a6d34af8e018ec0348885cbad8;>fca25e5 https://redirect.github.com/codehaus-plexus/plexus-archiver/issues/311;>#311 - provide fluent setter for usingDefaultExcludes flag in AbstractFileSet. https://github.com/codehaus-plexus/plexus-archiver/commit/9c0e021ab9d58dd8b05a74a5ba6c82f8070c8d93;>9c0e021 Bump org.apache.commons:commons-compress from 1.24.0 to 1.25.0 https://github.com/codehaus-plexus/plexus-archiver/commit/b353ae3240cfda1c23ec8c1d80e719af40698b66;>b353ae3 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-archiver/compare/plexus-archiver-4.9.0...plexus-archiver-4.9.1;>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 - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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)
