[jira] [Updated] (MENFORCER-417) requireUpperBoundDeps doesn't work when dependencies are managed
[
https://issues.apache.org/jira/browse/MENFORCER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MENFORCER-417:
--
Fix Version/s: (was: waiting-for-feedback)
> requireUpperBoundDeps doesn't work when dependencies are managed
>
>
> Key: MENFORCER-417
> URL: https://issues.apache.org/jira/browse/MENFORCER-417
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: James Howe
>Priority: Major
>
> {code:xml}
>
>
> {code}
> Example false-positive in a project using spring-boot-dependencies:
> {noformat}
> Failed while enforcing RequireUpperBoundDeps. The error(s) are [
> Require upper bound dependencies error for org.slf4j:slf4j-api:1.7.36 paths
> to dependency are:
> +-com.example:project:1.0-SNAPSHOT
>
> +-org.springframework.security.extensions:spring-security-saml2-core:1.0.10.RELEASE
> +-org.slf4j:slf4j-api:1.7.36 (managed) <-- org.slf4j:slf4j-api:1.7.29
> and
> +-com.example:project:1.0-SNAPSHOT
> +-com.github.zhanhb:thymeleaf-layout-dialect:3.0.0
> +-org.slf4j:slf4j-api:1.7.36 (managed) <-- org.slf4j:slf4j-api:1.7.32
> and
> +-com.example:project:1.0-SNAPSHOT
> +-org.springframework.boot:spring-boot-starter-logging:2.6.7 (managed) <--
> org.springframework.boot:spring-boot-starter-logging:2.6.7
> +-org.slf4j:jul-to-slf4j:1.7.36 (managed) <--
> org.slf4j:jul-to-slf4j:1.7.36
> +-org.slf4j:slf4j-api:1.7.36 (managed) <-- org.slf4j:slf4j-api:1.7.36
> ...
> {noformat}
> No version higher than 1.7.36 is listed anywhere, and at time of writing so
> such version has even been released (other than 2.0.0-alpha).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651425#comment-17651425
]
Slawomir Jaranowski commented on MENFORCER-405:
---
Please provide a simple project for reproduce.
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MENFORCER-405:
--
Fix Version/s: waiting-for-feedback
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-406) Enforcer plugin does not fail for duplicate dependency coming via transitive dependency
[
https://issues.apache.org/jira/browse/MENFORCER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MENFORCER-406:
--
Fix Version/s: waiting-for-feedback
> Enforcer plugin does not fail for duplicate dependency coming via transitive
> dependency
> ---
>
> Key: MENFORCER-406
> URL: https://issues.apache.org/jira/browse/MENFORCER-406
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Enforcer plugin not able to detect this duplicate dependency coming via
> transitive dependency and project gets build successfully. Is there any way
> to define any rule to enable the same?
>
> Defined Plugin in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-406) Enforcer plugin does not fail for duplicate dependency coming via transitive dependency
[
https://issues.apache.org/jira/browse/MENFORCER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651426#comment-17651426
]
Slawomir Jaranowski commented on MENFORCER-406:
---
Please provide a simple project for reproduce.
> Enforcer plugin does not fail for duplicate dependency coming via transitive
> dependency
> ---
>
> Key: MENFORCER-406
> URL: https://issues.apache.org/jira/browse/MENFORCER-406
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
>
> Enforcer plugin not able to detect this duplicate dependency coming via
> transitive dependency and project gets build successfully. Is there any way
> to define any rule to enable the same?
>
> Defined Plugin in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651428#comment-17651428
]
Slawomir Jaranowski commented on MENFORCER-405:
---
Please upgrade Maven to 3.8.6
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-406) Enforcer plugin does not fail for duplicate dependency coming via transitive dependency
[
https://issues.apache.org/jira/browse/MENFORCER-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651427#comment-17651427
]
Slawomir Jaranowski commented on MENFORCER-406:
---
Please upgrade Maven to 3.8.6
> Enforcer plugin does not fail for duplicate dependency coming via transitive
> dependency
> ---
>
> Key: MENFORCER-406
> URL: https://issues.apache.org/jira/browse/MENFORCER-406
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Enforcer plugin not able to detect this duplicate dependency coming via
> transitive dependency and project gets build successfully. Is there any way
> to define any rule to enable the same?
>
> Defined Plugin in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-431) Skip specific rules
[
https://issues.apache.org/jira/browse/MENFORCER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651430#comment-17651430
]
Slawomir Jaranowski commented on MENFORCER-431:
---
[~psiroky] ok
> Skip specific rules
> ---
>
> Key: MENFORCER-431
> URL: https://issues.apache.org/jira/browse/MENFORCER-431
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Minor
> Labels: up-for-grabs
>
> I can select rules like
> {code:java}
> mvn verify -Drules=alwaysPass,alwaysFail {code}
> or skip all rules with
> {code:java}
> mvn verify -Denforcer.skip
> {code}
> But what if I want to skip a single rule?
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies{code}
> Or multiple
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
> Vulnerabilities could be discovered and published at any time. This would be
> a useful to quickly allow my builds to continue, since I can't always upgrade
> dependencies as they appear.
> I don't want to turn off ALL my enforcer checks and I also dont want to list
> all the checks in the build command.
> Skipping a rule is an exceptional circumstance so I don't want to commit it
> to the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-684) replace flexmark-all dependency with core + only the used extensions
Herve Boutemy created DOXIA-684: --- Summary: replace flexmark-all dependency with core + only the used extensions Key: DOXIA-684 URL: https://issues.apache.org/jira/browse/DOXIA-684 Project: Maven Doxia Issue Type: Improvement Components: Module - Markdown Affects Versions: 2.0.0-M4, 1.11.1 Reporter: Herve Boutemy Fix For: 1.11.2, 2.0.0-M5 flexmark-all is easy to add to dependency, but downloads a bunch of unused extensions doing the effort to explicitely list only the used extensions will reduce Maven downloading some parts of the universe -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649048#comment-17649048 ] Herve Boutemy edited comment on MNG-7352 at 12/23/22 12:40 AM: --- Look at [61f1d01ba86e0765e0a78eb0b18571ee503055f6|https://github.com/apache/maven/commit/61f1d01ba86e0765e0a78eb0b18571ee503055f6]. [~hboutemy], well this class was public, you assumed it should be package private, though the deprecated one does not provide a public successor. I am included to make this public again. WDYT? was (Author: michael-o): Look at 61f1d01ba86e0765e0a78eb0b18571ee503055f6. [~hboutemy], well this class was public, you assumed it should be package private, though the deprecated one does not provide a public successor. I am included to make this public again. WDYT? > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate, > waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651448#comment-17651448 ] Herve Boutemy commented on MNG-7352: I admit that I don't fully get how all these "internal" classes are used: [~bananeweizen] can you share pointer to Git in Tycho please, for me to see? I suppose we won't really be able to hide this class. Notice: I don't know if this class has been defined as part of Maven API 4... > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate, > waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site-plugin] dependabot[bot] opened a new pull request, #118: Bump wagonVersion from 3.5.2 to 3.5.3
dependabot[bot] opened a new pull request, #118: URL: https://github.com/apache/maven-site-plugin/pull/118 Bumps `wagonVersion` from 3.5.2 to 3.5.3. Updates `wagon-provider-api` from 3.5.2 to 3.5.3 Commits https://github.com/apache/maven-wagon/commit/20b847446bb60f49af0428d592eadee774b5bff2";>20b8474 [maven-release-plugin] prepare release wagon-3.5.3 https://github.com/apache/maven-wagon/commit/baac9242909c26057797d040b2d5bdfa6db426ef";>baac924 [WAGON-631] Upgrade and clean up dependencies https://github.com/apache/maven-wagon/commit/e9a7f952969918ec72b79517c25f2fde4206a261";>e9a7f95 update Reproducible Builds badge link https://github.com/apache/maven-wagon/commit/f840c59358f15c13d65c532e085b63be3ed876e5";>f840c59 Fix Jenkins url https://github.com/apache/maven-wagon/commit/f654cd59c33a3efe3149dd1a2b418de49813f83e";>f654cd5 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-wagon/compare/wagon-3.5.2...wagon-3.5.3";>compare view Updates `wagon-webdav-jackrabbit` from 3.5.2 to 3.5.3 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-checkstyle-plugin] dependabot[bot] opened a new pull request, #104: Bump wagon-http-lightweight from 3.5.1 to 3.5.3
dependabot[bot] opened a new pull request, #104: URL: https://github.com/apache/maven-checkstyle-plugin/pull/104 Bumps wagon-http-lightweight from 3.5.1 to 3.5.3. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-checkstyle-plugin] dependabot[bot] commented on pull request #92: Bump wagon-http-lightweight from 3.5.1 to 3.5.2
dependabot[bot] commented on PR #92: URL: https://github.com/apache/maven-checkstyle-plugin/pull/92#issuecomment-1363620188 Superseded by #104. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-checkstyle-plugin] dependabot[bot] closed pull request #92: Bump wagon-http-lightweight from 3.5.1 to 3.5.2
dependabot[bot] closed pull request #92: Bump wagon-http-lightweight from 3.5.1 to 3.5.2 URL: https://github.com/apache/maven-checkstyle-plugin/pull/92 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1363647871 Rebased and squashed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] ajarmoniuk commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
ajarmoniuk commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1363654569 Hi @michael-o if I may, I think the current implementation is in line with the specification as I have a feeling that the specification has been based on it 😄 The problem is that the spec deviates from SemVer in how it treats non-standard qualifiers, like the "pfd" here. According to SemVer, all qualifiers should be treated as less than -.number whereas with "the spec" all non-standard qualifiers are treated as later than -.number. As is the case of "-pdf" which is later than the release. So, adding "pfd" as a recognised qualifier would mean that the spec also needs to be updated. Which is why it's a breaking change and not a bugfix. -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651501#comment-17651501
]
ASF GitHub Bot commented on MNG-7559:
-
ajarmoniuk commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363654569
Hi @michael-o if I may, I think the current implementation is in line with
the specification as I have a feeling that the specification has been based on
it 😄
The problem is that the spec deviates from SemVer in how it treats
non-standard qualifiers, like the "pfd" here. According to SemVer, all
qualifiers should be treated as less than -.number whereas with "the spec" all
non-standard qualifiers are treated as later than -.number.
As is the case of "-pdf" which is later than the release.
So, adding "pfd" as a recognised qualifier would mean that the spec also
needs to be updated. Which is why it's a breaking change and not a bugfix.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-3, 4.0.0-alpha-4,
> 4.0.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[ https://issues.apache.org/jira/browse/MNG-7559 ]
Andrzej Jarmoniuk deleted comment on MNG-7559:
was (Author: ajarmoniuk):
As pointed out by [~pzygielo], the behaviour is in line with the specification
at https://maven.apache.org/pom.html#version-order-specification.
Ticket may be closed.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-3, 4.0.0-alpha-4,
> 4.0.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-684) replace flexmark-all dependency with core + only the used extensions
[ https://issues.apache.org/jira/browse/DOXIA-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651510#comment-17651510 ] Michael Osipov commented on DOXIA-684: -- This is a VERY GOOD improvement. I never dared to do it. > replace flexmark-all dependency with core + only the used extensions > > > Key: DOXIA-684 > URL: https://issues.apache.org/jira/browse/DOXIA-684 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.11.1, 2.0.0-M4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 1.11.2, 2.0.0-M5 > > > flexmark-all is easy to add to dependency, but downloads a bunch of unused > extensions > doing the effort to explicitely list only the used extensions will reduce > Maven downloading some parts of the universe -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363702902
> Hi @michael-o if I may, I think the current implementation is in line with
the specification as I have a feeling that the specification has been based on
it 😄
>
> The problem is that the spec deviates from SemVer in how it treats
non-standard qualifiers, like the "pfd" here. According to SemVer, all
qualifiers should be treated as less than -.number whereas with "the spec" all
non-standard qualifiers are treated as later than -.number.
>
> As is the case of "-pdf" which is later than the release.
>
> So this:
>
> > The docs say:
> > > else ".qualifier" = "-qualifier" < "-number" < ".number
>
> is not exactly true.
>
> ```java
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new DefaultArtifactVersion( "2.3" ).compareTo( new
DefaultArtifactVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> ```
>
> ```
> java.lang.AssertionError:
> Expected: a value greater than <0>
> but: <-2> was less than <0>
> ```
>
> So, adding "pfd" as a recognised qualifier would mean that the spec also
needs to be updated. Which is why it's a breaking change and not a bugfix.
>
> Frankly, to me it looks like this behaviour contradicts the statement that
"-qualifier" < "-number", but I've long given up on that.
I have just re-read the spec. It says:
If version strings are syntactically correct [Semantic Versioning
1.0.0](https://semver.org/spec/v1.0.0.html) version numbers, then in almost all
cases version comparison follows the precedence rules outlined in that
specificationMaven does not consider any semantics implied by that
specificationNon-numeric tokens ("qualifiers") have the alphabetical order,
except for the following tokens which come first in this order
So what it does is just use the *syntax* of SemVer 1.0 and *not* the
semantics. It considers only a new qualifiers as pre-release and not all, e.g.,
sp for service pack is a post-GA qualifier. So to me this change is change of
the specs since it wants add more qualifiers to the pre-release state.
So my verdict based on my understanding the dot vs hyphen issue was real and
I can see it with a few manual tests. Others are not.
I will remove this ticket from 3.x for obvious reasons. I think that the
version scheme requires an update in 4.0, but that is a different discussion.
Opinions?
Side note:
Looking at SemVer 2.0 I am not really happy with it:
* It allows very complex qualifiers. Don't know wether that is really
necessary
* Our `SNAPSHOT` qualifier cannot be covered
* Build qualfiiers aren't release qualifiers for me
* I don't see how one can map custom qualifiers (post-release) for the case
I have depicted earlier, those aren't build qualifiers.
* I don't see how a build qualifier makes sense after post-release where a
release is supposed to be immutable and identical according to SemVer
PS: I am not happy with the ambiguity/lack of precision of the current spec
--
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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651514#comment-17651514
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363702902
> Hi @michael-o if I may, I think the current implementation is in line with
the specification as I have a feeling that the specification has been based on
it 😄
>
> The problem is that the spec deviates from SemVer in how it treats
non-standard qualifiers, like the "pfd" here. According to SemVer, all
qualifiers should be treated as less than -.number whereas with "the spec" all
non-standard qualifiers are treated as later than -.number.
>
> As is the case of "-pdf" which is later than the release.
>
> So this:
>
> > The docs say:
> > > else ".qualifier" = "-qualifier" < "-number" < ".number
>
> is not exactly true.
>
> ```java
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new DefaultArtifactVersion( "2.3" ).compareTo( new
DefaultArtifactVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> ```
>
> ```
> java.lang.AssertionError:
> Expected: a value greater than <0>
> but: <-2> was less than <0>
> ```
>
> So, adding "pfd" as a recognised qualifier would mean that the spec also
needs to be updated. Which is why it's a breaking change and not a bugfix.
>
> Frankly, to me it looks like this behaviour contradicts the statement that
"-qualifier" < "-number", but I've long given up on that.
I have just re-read the spec. It says:
If version strings are syntactically correct [Semantic Versioning
1.0.0](https://semver.org/spec/v1.0.0.html) version numbers, then in almost all
cases version comparison follows the precedence rules outlined in that
specificationMaven does not consider any semantics implied by that
specificationNon-numeric tokens ("qualifiers") have the alphabetical order,
except for the following tokens which come first in this order
So what it does is just use the *syntax* of SemVer 1.0 and *not* the
semantics. It considers only a new qualifiers as pre-release and not all, e.g.,
sp for service pack is a post-GA qualifier. So to me this change is change of
the specs since it wants add more qualifiers to the pre-release state.
So my verdict based on my understanding the dot vs hyphen issue was real and
I can see it with a few manual tests. Others are not.
I will remove this ticket from 3.x for obvious reasons. I think that the
version scheme requires an update in 4.0, but that is a different discussion.
Opinions?
Side note:
Looking at SemVer 2.0 I am not really happy with it:
* It allows very complex qualifiers. Don't know wether that is really
necessary
* Our `SNAPSHOT` qualifier cannot be covered
* Build qualfiiers aren't release qualifiers for me
* I don't see how one can map custom qualifiers (post-release) for the case
I have depicted earlier, those aren't build qualifiers.
* I don't see how a build qualifier makes sense after post-release where a
release is supposed to be immutable and identical according to SemVer
PS: I am not happy with the ambiguity/lack of precision of the current spec
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-3, 4.0.0-alpha-4,
> 4.0.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7559:
Fix Version/s: 4.x / Backlog
(was: 4.0.0)
(was: 3.8.x-candidate)
(was: 3.9.0)
(was: 4.0.0-alpha-3)
(was: 4.0.0-alpha-4)
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.x / Backlog
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7559:
---
Assignee: (was: Michael Osipov)
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Priority: Major
> Fix For: 4.x / Backlog
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7641) Upgrade Maven Wagon to 3.5.3
[ https://issues.apache.org/jira/browse/MNG-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7641: Fix Version/s: 4.0.0-alpha-4 (was: 4.0.0-alpha-2) > Upgrade Maven Wagon to 3.5.3 > > > Key: MNG-7641 > URL: https://issues.apache.org/jira/browse/MNG-7641 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.7, 3.9.0, 4.0.0-alpha-4, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651517#comment-17651517 ] Michael Osipov commented on MNG-7352: - Without a documented alternative this must be exposed. Of course, we could deprecate this class as well when we have a REAL alternative. > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate, > waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7641) Upgrade Maven Wagon to 3.5.3
[ https://issues.apache.org/jira/browse/MNG-7641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7641. --- Resolution: Fixed Fixed with [e73a0b00fde80c400a6d854ec0c2ba7436325eed|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=e73a0b00fde80c400a6d854ec0c2ba7436325eed], with [353eea33c1fa0d68eda3b813543036d9345e08b8|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=353eea33c1fa0d68eda3b813543036d9345e08b8] for maven-3.9.x branch, with [91ddc374426eafb5ba6bd02c295867b2c4aa867e|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=91ddc374426eafb5ba6bd02c295867b2c4aa867e] for maven-3.8.x branch. > Upgrade Maven Wagon to 3.5.3 > > > Key: MNG-7641 > URL: https://issues.apache.org/jira/browse/MNG-7641 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.7, 3.9.0, 4.0.0-alpha-4, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-6801) MavenXpp3Writer doesn't retain order of properties
[ https://issues.apache.org/jira/browse/MNG-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6801: Fix Version/s: (was: 3.8.x-candidate) > MavenXpp3Writer doesn't retain order of properties > -- > > Key: MNG-6801 > URL: https://issues.apache.org/jira/browse/MNG-6801 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Liana Lupsa >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-2, 4.0.0 > > > Context: > We are using pipeline-utility-steps-plugin which is a jenkins plugin which > uses the following classes: > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/ReadMavenPomStep.java]. > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/WriteMavenPomStep.java#L32] > In our Jenkins file we have a stage that overwrites the version in the pom > with the computed version and for this we need pipeline-utility-steps-plugin. > The problem is that the tags in the pom.xml are never retained in the same > order. The elements in the pom file are completelly rearranged. > For consistency reasons and idempotency we need to retain the structure and > simply update one line. > Status: > After evaluating the plugin code we noticed that it uses: > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/WriteMavenPomStep.java#L32] > and imports: > import org.apache.maven.model.io.xpp3.MavenXpp3Writer; > with > [https://maven.apache.org/ref/3.3.9/maven-model/apidocs/src-html/org/apache/maven/model/io/xpp3/MavenXpp3Writer.html] > which uses > XmlSerializer serializer = new MXSerializer(); > > [https://github.com/sonatype/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/xml/pull/MXSerializer.java] > We think that maven XmlSerializer causes this problem. > Example of the pom.xml changes: > first build trigger: > run 1: > > 3.1.0 > 1.10.19 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > > run 2: > > 1.10.19 > 3.1.0 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > > and run 3: > > 3.1.0 > 1.10.19 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #576: [NO-JIRA] Refactor integration tests module
slawekjaranowski commented on PR #576: URL: https://github.com/apache/maven-surefire/pull/576#issuecomment-1362595584 @SimonBaars can you resolve conflicts? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1362597943 > > What I now understand is that arbitrary qualifiers are not considered _after_ `GA`. Following example: I need to fork commons-io 2.12.0 for the company and it will be named `2.12.0-company-1` through `2.12.0-company-5`. I would expect that those come _after_ the GA because I had to apply custom patches. > > I do this at work for various reasons and if you check libs bundled with Nexus they have `SONATYPE` qualifier. > > you may want to use the + instead of - as in: 2.12.0+company-1 > > maybe a third PR to be merged before for this case ? Right, according to SemVer my approach is wrong. Thanks for the clarification. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1362598207 @sultan Please rebase this PR on top of current master. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #901: fix version comparison
michael-o commented on PR #901: URL: https://github.com/apache/maven/pull/901#issuecomment-1362598742 This seems to be superseded. -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651189#comment-17651189
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1362597943
> > What I now understand is that arbitrary qualifiers are not considered
_after_ `GA`. Following example: I need to fork commons-io 2.12.0 for the
company and it will be named `2.12.0-company-1` through `2.12.0-company-5`. I
would expect that those come _after_ the GA because I had to apply custom
patches.
> > I do this at work for various reasons and if you check libs bundled with
Nexus they have `SONATYPE` qualifier.
>
> you may want to use the + instead of - as in: 2.12.0+company-1
>
> maybe a third PR to be merged before for this case ?
Right, according to SemVer my approach is wrong. Thanks for the
clarification.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651190#comment-17651190
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1362598207
@sultan Please rebase this PR on top of current master.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o closed pull request #901: fix version comparison
michael-o closed pull request #901: fix version comparison URL: https://github.com/apache/maven/pull/901 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on a diff in pull request #570: [SUREFIRE-2119] - Sanitize failIfNoSpecifiedTests prefix in failsafe
slawekjaranowski commented on code in PR #570: URL: https://github.com/apache/maven-surefire/pull/570#discussion_r1055259627 ## maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java: ## @@ -130,12 +130,24 @@ private boolean useFile; /** - * Set this to "true" to cause a failure if none of the tests specified in -Dtest=... are run. Defaults to + * Set this to "true" to cause a failure if none of the tests specified in -Dit.test=... are run. Defaults to * "true". * * @since 2.12 + * @deprecated Since 3.0.0-M8, use "failsafe.failIfNoSpecifiedTests" instead. */ +@Deprecated @Parameter( property = "it.failIfNoSpecifiedTests", defaultValue = "true" ) +private boolean failIfNoSpecifiedTestsDeprecated; + +/** + * Set this to "true" to cause a failure if none of the tests specified in -Dit.test=... are run. Defaults to + * "true". + * Replacing "it.failIfNoSpecifiedTests" to be consistent with surefire plugin. Review Comment: as `true` is the default value, I would start documentation from something like > Set this to false to prevent a failure if 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
[GitHub] [maven-mvnd] mthmulders commented on issue #758: 1.0.0-m1 slower than 0.8.2
mthmulders commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362616130 > Yes, exactly this. Thanks for clarifying. I'm wondering if there's a measurable difference if you disable build/consumer POM decoupling. From [MNG-6656](https://issues.apache.org/jira/browse/MNG-6656), it should be possible to disable that with `-Dmaven.experimental.buildconsumer=true`. Is that something you could try, please? -- 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-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7352: Fix Version/s: 3.8.x-candidate 3.9.0-candidate 4.0.x-candidate > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate, > waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-wrapper] nicoloboschi commented on pull request #65: [MWRAPPER-80] support maven-mvnd
nicoloboschi commented on PR #65: URL: https://github.com/apache/maven-wrapper/pull/65#issuecomment-1362638693 This is a great feature! @bmarwell @amitmisra-ww @slawekjaranowski PTAL -- 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] (MWRAPPER-80) Support maven-mvnd as a maven distribution
[ https://issues.apache.org/jira/browse/MWRAPPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651206#comment-17651206 ] ASF GitHub Bot commented on MWRAPPER-80: nicoloboschi commented on PR #65: URL: https://github.com/apache/maven-wrapper/pull/65#issuecomment-1362638693 This is a great feature! @bmarwell @amitmisra-ww @slawekjaranowski PTAL > Support maven-mvnd as a maven distribution > -- > > Key: MWRAPPER-80 > URL: https://issues.apache.org/jira/browse/MWRAPPER-80 > Project: Maven Wrapper > Issue Type: New Feature > Components: Maven Wrapper Scripts >Reporter: James Z.M. Gao >Priority: Major > > Here is a proposal method to integrate maven-mvnd. > When set distributionUrl to a maven-mvnd downloading url, the wrapper should > distinguish then download/install/run the maven-mvnd on the fly. The script > should take own the os/hardware detecting to select a proper native version. > For example: > * manual select platform: > distributionUrl=[https://downloads.apache.org/maven/mvnd/0.8.2/maven-mvnd-0.8.2-darwin-amd64.zip] > * auto select platform: > distributionUrl=[https://downloads.apache.org/maven/mvnd/0.8.2/maven-mvnd-0.8.2-bin.zip] > In the auto mode, the script can select the real platform via the result of > "uname -a", or fallback to the pure java version for unknown platform. For > `distributionSha256Sum`, we also need new pattern to support multiple > checksum, such as > > * distributionSha256Sum=darwin-aarch64:111;linux-amd64:222 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651222#comment-17651222
]
Tamas Cservenak commented on MRESOLVER-308:
---
Third round, the transports can be considered feature complete (while the
project has now quite a lot of redundancy, like the test HTTP server, this
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT
Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central
A B
wagon 00:49 01:18
native 00:45 00:50
jetty 00:45 00:51
okhttp 00:53 00:51
java11 00:41 00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is
slowest, while native is rock solid and performant, but both are (and can be
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP
socket used, which may be interesting on CI server for example).
OkHttp is faster thab wagon, but by a margin, plus it pulls in kotlin, that is
I think undesired, so I'd eliminate it.
The two remaining contenders, Jetty and Java11 HttpClient are both interesting.
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient
is need of Java11.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651222#comment-17651222
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/22/22 11:02 AM:
--
Third round, the transports can be considered feature complete (while the
project has now quite a lot of redundancy, like the test HTTP server, this
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT
Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central
A B
wagon 00:49 01:18
native 00:45 00:50
jetty 00:45 00:51
okhttp 00:53 00:51
java11 00:41 00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is
slowest, while native is rock solid and performant, but both are (and can be
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP
socket used, which may be interesting on CI server for example).
OkHttp is faster then wagon, but by a margin, plus it pulls in kotlin, that is
I think undesired, so I'd eliminate it.
The two remaining contenders, Jetty and Java11 HttpClient are both interesting.
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient
is need of Java11.
was (Author: cstamas):
Third round, the transports can be considered feature complete (while the
project has now quite a lot of redundancy, like the test HTTP server, this
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT
Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central
A B
wagon 00:49 01:18
native 00:45 00:50
jetty 00:45 00:51
okhttp 00:53 00:51
java11 00:41 00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is
slowest, while native is rock solid and performant, but both are (and can be
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP
socket used, which may be interesting on CI server for example).
OkHttp is faster thab wagon, but by a margin, plus it pulls in kotlin, that is
I think undesired, so I'd eliminate it.
The two remaining contenders, Jetty and Java11 HttpClient are both interesting.
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient
is need of Java11.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651222#comment-17651222
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/22/22 11:03 AM:
--
Third round, the transports can be considered feature complete (while the
project has now quite a lot of redundancy, like the test HTTP server, this
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT
Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central
A B
wagon 00:49 01:18
native 00:45 00:50
jetty 00:45 00:51
okhttp 00:53 00:51
java11 00:41 00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is
slowest, while native is rock solid and performant, but both are (and can be
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP
socket used, which may be interesting on CI server for example).
OkHttp is faster then wagon, but by a margin, plus it pulls in kotlin, that is
I think undesired, so I'd eliminate it.
The two remaining contenders, Jetty and Java11 HttpClient are both interesting.
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient
is requirement of Java11 (but it is currently circumvented cleanly, so this
transport can exist even in Maven 3.9.0 but remains dormant if Java8 used,
while activates when Java11+ used).
was (Author: cstamas):
Third round, the transports can be considered feature complete (while the
project has now quite a lot of redundancy, like the test HTTP server, this
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT
Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central
A B
wagon 00:49 01:18
native 00:45 00:50
jetty 00:45 00:51
okhttp 00:53 00:51
java11 00:41 00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is
slowest, while native is rock solid and performant, but both are (and can be
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP
socket used, which may be interesting on CI server for example).
OkHttp is faster then wagon, but by a margin, plus it pulls in kotlin, that is
I think undesired, so I'd eliminate it.
The two remaining contenders, Jetty and Java11 HttpClient are both interesting.
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient
is need of Java11.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #112: Adding support for externally passed random seed and printing used seed on console
slawekjaranowski commented on PR #112: URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-1362708234 I hope that this feature was implemented in https://issues.apache.org/jira/browse/SUREFIRE-2055 at long last. So I close this. Thanks everybody for contributions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski closed pull request #112: Adding support for externally passed random seed and printing used seed on console
slawekjaranowski closed pull request #112: Adding support for externally passed random seed and printing used seed on console URL: https://github.com/apache/maven-surefire/pull/112 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] sultan commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
sultan commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1362760892 > @sultan Please rebase this PR on top of current master. rebased -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651252#comment-17651252
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1362760892
> @sultan Please rebase this PR on top of current master.
rebased
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPOM-387) Enforcer enforceBytecodeVersion applies to everything
Tamas Cservenak created MPOM-387:
Summary: Enforcer enforceBytecodeVersion applies to everything
Key: MPOM-387
URL: https://issues.apache.org/jira/browse/MPOM-387
Project: Maven POMs
Issue Type: Bug
Components: asf
Reporter: Tamas Cservenak
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use Java 11 dependencies on a project that
is otherwise Java8.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-387) Enforcer enforceBytecodeVersion applies to everything
[
https://issues.apache.org/jira/browse/MPOM-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MPOM-387:
-
Description:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise producing Java 8 artifact.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
was:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise Java 8.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
> Enforcer enforceBytecodeVersion applies to everything
> -
>
> Key: MPOM-387
> URL: https://issues.apache.org/jira/browse/MPOM-387
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Reporter: Tamas Cservenak
>Priority: Major
>
> In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without
> any special configuration, which IMHO is wrong.
> For example, this rule prevents to use *Java 11 test-only dependencies* on a
> project that is otherwise producing Java 8 artifact.
> IMHO, applying this rule on everything makes no sense, at lest test scope
> should be ignored (if not provided as well, as there one have no control what
> is provided as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-387) Enforcer enforceBytecodeVersion applies to everything
[
https://issues.apache.org/jira/browse/MPOM-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MPOM-387:
-
Description:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise Java 8.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
was:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use Java 11 dependencies on a project that
is otherwise Java8.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
> Enforcer enforceBytecodeVersion applies to everything
> -
>
> Key: MPOM-387
> URL: https://issues.apache.org/jira/browse/MPOM-387
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Reporter: Tamas Cservenak
>Priority: Major
>
> In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without
> any special configuration, which IMHO is wrong.
> For example, this rule prevents to use *Java 11 test-only dependencies* on a
> project that is otherwise Java 8.
> IMHO, applying this rule on everything makes no sense, at lest test scope
> should be ignored (if not provided as well, as there one have no control what
> is provided as well).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-387) Enforcer enforceBytecodeVersion applies to everything
[
https://issues.apache.org/jira/browse/MPOM-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MPOM-387:
-
Description:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise producing Java 8 artifact.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as one have no control what is
provided).
was:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise producing Java 8 artifact.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as there one have no control what
is provided as well).
> Enforcer enforceBytecodeVersion applies to everything
> -
>
> Key: MPOM-387
> URL: https://issues.apache.org/jira/browse/MPOM-387
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Reporter: Tamas Cservenak
>Priority: Major
>
> In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without
> any special configuration, which IMHO is wrong.
> For example, this rule prevents to use *Java 11 test-only dependencies* on a
> project that is otherwise producing Java 8 artifact.
> IMHO, applying this rule on everything makes no sense, at lest test scope
> should be ignored (if not provided as well, as one have no control what is
> provided).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-387) Enforcer enforceBytecodeVersion applies to everything
[
https://issues.apache.org/jira/browse/MPOM-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MPOM-387:
-
Component/s: maven
(was: asf)
Description:
In Maven Parent POM the enforcer {{enforceBytecodeVersion}} is added without
any special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise producing Java 8 artifact.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as one have no control what is
provided).
was:
In ASF Parent POM the enforcer {{enforceBytecodeVersion}} is added without any
special configuration, which IMHO is wrong.
For example, this rule prevents to use *Java 11 test-only dependencies* on a
project that is otherwise producing Java 8 artifact.
IMHO, applying this rule on everything makes no sense, at lest test scope
should be ignored (if not provided as well, as one have no control what is
provided).
> Enforcer enforceBytecodeVersion applies to everything
> -
>
> Key: MPOM-387
> URL: https://issues.apache.org/jira/browse/MPOM-387
> Project: Maven POMs
> Issue Type: Bug
> Components: maven
>Reporter: Tamas Cservenak
>Priority: Major
>
> In Maven Parent POM the enforcer {{enforceBytecodeVersion}} is added without
> any special configuration, which IMHO is wrong.
> For example, this rule prevents to use *Java 11 test-only dependencies* on a
> project that is otherwise producing Java 8 artifact.
> IMHO, applying this rule on everything makes no sense, at lest test scope
> should be ignored (if not provided as well, as one have no control what is
> provided).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] IvanSmurygin opened a new issue, #759: NullPointerException
IvanSmurygin opened a new issue, #759: URL: https://github.com/apache/maven-mvnd/issues/759 Hello! I use mvnd with some multimodule project (around 30 dependent modules), during the build the next exception is thrown ``` [ERROR] Internal error: java.lang.NullPointerException -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:120) at org.apache.maven.cli.DaemonMavenCli.execute(DaemonMavenCli.java:687) at org.apache.maven.cli.DaemonMavenCli.doMain(DaemonMavenCli.java:239) at org.apache.maven.cli.DaemonMavenCli.main(DaemonMavenCli.java:215) at org.mvndaemon.mvnd.daemon.Server.handle(Server.java:572) at org.mvndaemon.mvnd.daemon.Server.client(Server.java:256) at org.mvndaemon.mvnd.daemon.Server.accept(Server.java:224) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.NullPointerException: null at java.base/java.util.Objects.requireNonNull(Objects.java:221) at com.gradle.maven.a.a.c.h.a(SourceFile:86) at com.gradle.maven.internal.GradleEnterpriseLifecycleManager.afterSessionEnd(SourceFile:137) at org.apache.maven.DefaultMaven.afterSessionEnd(DefaultMaven.java:354) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) ... 7 common frames omitted [ERROR] [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/InternalErrorException ``` ``` mvnd -version mvnd 0.8.2 darwin-amd64 native client (2bba2d6a4d3a5012ddf9f1f42a22784cad4011e3) Terminal: org.jline.terminal.impl.PosixSysTerminal with pty org.jline.terminal.impl.jansi.osx.OsXNativePty [WARN] Failed to initialize spy com.gradle.maven.internal.GradleEnterpriseLifecycleManager: build operation notification valve already started Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /usr/local/Cellar/mvnd/0.8.2/libexec/mvn Java version: 11.0.16.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@11/11.0.16.1/libexec/openjdk.jdk/Contents/Home Default locale: en_DE, platform encoding: UTF-8 OS name: "mac os x", version: "12.6.2", arch: "x86_64", family: "mac" ``` -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell opened a new pull request, #74: [BUILD] add shellcheck
bmarwell opened a new pull request, #74: URL: https://github.com/apache/maven-wrapper/pull/74 * WHY? => Because of bashisms in this PR: https://github.com/apache/maven-wrapper/pull/65 * TODO: maybe change the output format? => https://github.com/koalaman/shellcheck/wiki/Integration#machine-parsable-output --- Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MWRAPPER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell commented on pull request #61: Switch to JUnit Jupiter
bmarwell commented on PR #61: URL: https://github.com/apache/maven-wrapper/pull/61#issuecomment-1362934686 @timtebeek it is now Java 8 -- would you like to change it back? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell commented on a diff in pull request #61: Switch to JUnit Jupiter
bmarwell commented on code in PR #61: URL: https://github.com/apache/maven-wrapper/pull/61#discussion_r1055548475 ## maven-wrapper/pom.xml: ## @@ -34,18 +34,18 @@ under the License. Maven Wrapper Jar download, installs and launches installed target Maven distribution as part of Maven Wrapper scripts run. - - junit - junit - 4.13.2 - test - org.hamcrest hamcrest-core 2.2 test + + org.junit.jupiter + junit-jupiter + 5.9.0 + test + Review Comment: Please import the bom in dependency management ## maven-wrapper/pom.xml: ## @@ -34,18 +34,18 @@ under the License. Maven Wrapper Jar download, installs and launches installed target Maven distribution as part of Maven Wrapper scripts run. - - junit - junit - 4.13.2 - test - org.hamcrest hamcrest-core 2.2 test + + org.junit.jupiter + junit-jupiter + 5.9.0 Review Comment: Optional: Extract to property (after switching to bom) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell commented on pull request #72: Bump mockito-core from 4.6.1 to 4.10.0
bmarwell commented on PR #72: URL: https://github.com/apache/maven-wrapper/pull/72#issuecomment-1362942210 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell commented on pull request #68: Bump plexus-archiver from 4.2.5 to 4.6.0
bmarwell commented on PR #68: URL: https://github.com/apache/maven-wrapper/pull/68#issuecomment-1362945871 @dependabot recreate -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on issue #758: 1.0.0-m1 slower than 0.8.2
gnodet commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362946968 I haven't pinpoint the exact problem, however mind 1.0.0-m1 is noticeably slower than 0.8.2. More significant, running `mvn foo` (so that all projects are parsed but no plugin is executed) was expectedly faster with mind 0.8.2 than maven 3.8.6, but mvn 1.0.0-m1 is slower than maven 4.0.0-alpha-3. This clearly points toward a problem in mvnd 1.0.0-m1 imho... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] dependabot[bot] commented on pull request #68: Bump plexus-archiver from 4.2.5 to 4.6.0
dependabot[bot] commented on PR #68: URL: https://github.com/apache/maven-wrapper/pull/68#issuecomment-1362949155 Looks like org.codehaus.plexus:plexus-archiver is up-to-date now, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] dependabot[bot] closed pull request #68: Bump plexus-archiver from 4.2.5 to 4.6.0
dependabot[bot] closed pull request #68: Bump plexus-archiver from 4.2.5 to 4.6.0 URL: https://github.com/apache/maven-wrapper/pull/68 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] bmarwell merged pull request #72: Bump mockito-core from 4.6.1 to 4.10.0
bmarwell merged PR #72: URL: https://github.com/apache/maven-wrapper/pull/72 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] KemalSoysal commented on issue #710: Too many open files on Mac OS with JDK 11 and mvnd 0.8.2
KemalSoysal commented on issue #710: URL: https://github.com/apache/maven-mvnd/issues/710#issuecomment-1362959596 I ran into a similar issue when I tried to generate sources with a java program that loads a lot of jars itself. I started it in an own class world. After the goal was finished, my custom plugin was not able to unload the classloader. So after a couple of goal invocations, the maxfiles limit was reached. When the maven process was shut down they were released. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas opened a new pull request, #231: [MRESOLVER-308] HTTP transport showdown.
cstamas opened a new pull request, #231: URL: https://github.com/apache/maven-resolver/pull/231 Introduces 3 new transport: Jetty HttpClient 10.x, OkHttp 4.x and Java 11 HttpClient based ones. These are all HTTP/2 capable transports. Also, some reshuffle around HTTP tests, made them reusable to be able to use them in all HTTP based transports. --- https://issues.apache.org/jira/browse/MRESOLVER-308 -- 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-308) HTTP transport showdown
[ https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651314#comment-17651314 ] ASF GitHub Bot commented on MRESOLVER-308: -- cstamas opened a new pull request, #231: URL: https://github.com/apache/maven-resolver/pull/231 Introduces 3 new transport: Jetty HttpClient 10.x, OkHttp 4.x and Java 11 HttpClient based ones. These are all HTTP/2 capable transports. Also, some reshuffle around HTTP tests, made them reusable to be able to use them in all HTTP based transports. --- https://issues.apache.org/jira/browse/MRESOLVER-308 > HTTP transport showdown > --- > > Key: MRESOLVER-308 > URL: https://issues.apache.org/jira/browse/MRESOLVER-308 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > For HTTP protocol resolver currently provides following transports: > * transport-wagon that uses Maven 2.x Wagon, that among other protocols > supports HTTP/1.1 as well > * transport-http that uses directly Apache HttpClient 4.x supporting > HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all > of remote repositories emit those in headers, sparing one HTTP round-trip) > As we saw, is very easy to outperform these as: > * Maven Central supports HTTP/1.1 but also HTTP/2 > * HTTP/3 is on the way as well > An experiment involving Jetty Client far outperformed both of existing > transports, most probably due HTTP/2 support. > So, clients we should consider: > * Jetty Client > * OkHTTP > * Java 11 HttpClient > Point is, to invest into something that (ideally) transparently supports > HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be > transparently supported (Jetty 12 works on that). We could then simply > compare these implementations, count in pros and cons, and decide where we > want to go, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #231: [MRESOLVER-308] HTTP transport showdown.
cstamas commented on PR #231: URL: https://github.com/apache/maven-resolver/pull/231#issuecomment-1362976250 The shared test is "lifted" from existing "native" (Apache HttpClient) tests, and it is strictly blocking, so assertions happens that body is not touched, while new clients do some things "ahead" to optimize, so still remains how to settle these (IMHO minor) differences, but to not loose any notable information. All 3 new transport UT passes when these fine grained assertions are removed. -- 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-308) HTTP transport showdown
[ https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651318#comment-17651318 ] ASF GitHub Bot commented on MRESOLVER-308: -- cstamas commented on PR #231: URL: https://github.com/apache/maven-resolver/pull/231#issuecomment-1362976250 The shared test is "lifted" from existing "native" (Apache HttpClient) tests, and it is strictly blocking, so assertions happens that body is not touched, while new clients do some things "ahead" to optimize, so still remains how to settle these (IMHO minor) differences, but to not loose any notable information. All 3 new transport UT passes when these fine grained assertions are removed. > HTTP transport showdown > --- > > Key: MRESOLVER-308 > URL: https://issues.apache.org/jira/browse/MRESOLVER-308 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > For HTTP protocol resolver currently provides following transports: > * transport-wagon that uses Maven 2.x Wagon, that among other protocols > supports HTTP/1.1 as well > * transport-http that uses directly Apache HttpClient 4.x supporting > HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all > of remote repositories emit those in headers, sparing one HTTP round-trip) > As we saw, is very easy to outperform these as: > * Maven Central supports HTTP/1.1 but also HTTP/2 > * HTTP/3 is on the way as well > An experiment involving Jetty Client far outperformed both of existing > transports, most probably due HTTP/2 support. > So, clients we should consider: > * Jetty Client > * OkHTTP > * Java 11 HttpClient > Point is, to invest into something that (ideally) transparently supports > HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be > transparently supported (Jetty 12 works on that). We could then simply > compare these implementations, count in pros and cons, and decide where we > want to go, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1362992848 As far as I understand now this is a change in behavior? If so, I cannot apply to 3.8.x because it is not a bugfix. Is it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651324#comment-17651324
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1362992848
As far as I understand now this is a change in behavior? If so, I cannot
apply to 3.8.x because it is not a bugfix. Is it?
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas merged pull request #227: [MRESOLVER-303] Make checksum detection reusable
cstamas merged PR #227: URL: https://github.com/apache/maven-resolver/pull/227 -- 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-303) Make checksum detection reusable
[ https://issues.apache.org/jira/browse/MRESOLVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651326#comment-17651326 ] ASF GitHub Bot commented on MRESOLVER-303: -- cstamas merged PR #227: URL: https://github.com/apache/maven-resolver/pull/227 > Make checksum detection reusable > > > Key: MRESOLVER-303 > URL: https://issues.apache.org/jira/browse/MRESOLVER-303 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > As currently it is confined into M2 layout implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas merged pull request #228: [MRESOLVER-305] Handle blocked state at connector level
cstamas merged PR #228: URL: https://github.com/apache/maven-resolver/pull/228 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651327#comment-17651327
]
ASF GitHub Bot commented on MRESOLVER-305:
--
cstamas merged PR #228:
URL: https://github.com/apache/maven-resolver/pull/228
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by:
> org.apache.maven.wagon.providers.http.httpclient.conn.HttpHostConnectE
[jira] [Assigned] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-305:
-
Assignee: Tamas Cservenak
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by:
> org.apache.maven.wagon.providers.http.httpclient.conn.HttpHostConnectException:
> Connect to 0.0.0.0:80 [/0.0.0.0] failed: Operatio
[jira] [Closed] (MRESOLVER-305) Evaluate blocked repositories also when retrieving metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-305.
-
Resolution: Fixed
> Evaluate blocked repositories also when retrieving metadata
> ---
>
> Key: MRESOLVER-305
> URL: https://issues.apache.org/jira/browse/MRESOLVER-305
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 1.9.3
>
>
> With MRESOLVER-166 support for blocked repositories have been added.
> Unfortunately a good error message is only emitted in
> https://github.com/apache/maven-resolver/blob/a8c0b56a614b1759f0384ab3326c301d3a7221a7/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L579-L590.
> This does not kick in though when using low-level API like
> {{org.eclipse.aether.RepositorySystem.resolveVersion()}} which just leads
> to a timeout when trying to connect to the artificial mirror URL 0.0.0.0:
> {code}
> [WARNING] Could not transfer metadata .../maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0//maven-metadata.xml
> org.eclipse.aether.transfer.MetadataTransferException: Could not transfer
> metadata com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/.../maven-metadata.xml
> at
> org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed
> (MetadataTransportListener.java:52)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:369)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by: org.apache.maven.wagon.TransferFailedException: transfer failed
> for http://0.0.0.0/./maven-metadata.xml
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1250)
> at
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:546)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:430)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:407)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
> (BasicRepositoryConnector.java:457)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
> (BasicRepositoryConnector.java:364)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
> (BasicRepositoryConnector.java:628)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
> (BasicRepositoryConnector.java:235)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run
> (DefaultMetadataResolver.java:573)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
> (RunnableErrorForwarder.java:75)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:635)
> at java.lang.Thread.run (Thread.java:833)
> Caused by:
> org.apache.maven.wagon.providers.http.httpclient.conn.HttpHostConnectException:
> Connect to 0.0.0.0:80 [/0.0.0.0] failed: Operation timed out
> at
> org.apache.maven.wagon.providers
[jira] [Closed] (MRESOLVER-303) Make checksum detection reusable
[ https://issues.apache.org/jira/browse/MRESOLVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-303. - Resolution: Fixed > Make checksum detection reusable > > > Key: MRESOLVER-303 > URL: https://issues.apache.org/jira/browse/MRESOLVER-303 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > As currently it is confined into M2 layout implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-308) HTTP transport showdown
[ https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-308: - Assignee: Tamas Cservenak > HTTP transport showdown > --- > > Key: MRESOLVER-308 > URL: https://issues.apache.org/jira/browse/MRESOLVER-308 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > For HTTP protocol resolver currently provides following transports: > * transport-wagon that uses Maven 2.x Wagon, that among other protocols > supports HTTP/1.1 as well > * transport-http that uses directly Apache HttpClient 4.x supporting > HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all > of remote repositories emit those in headers, sparing one HTTP round-trip) > As we saw, is very easy to outperform these as: > * Maven Central supports HTTP/1.1 but also HTTP/2 > * HTTP/3 is on the way as well > An experiment involving Jetty Client far outperformed both of existing > transports, most probably due HTTP/2 support. > So, clients we should consider: > * Jetty Client > * OkHTTP > * Java 11 HttpClient > Point is, to invest into something that (ideally) transparently supports > HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be > transparently supported (Jetty 12 works on that). We could then simply > compare these implementations, count in pros and cons, and decide where we > want to go, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-308) HTTP transport showdown
[ https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-308: -- Fix Version/s: 1.9.3 > HTTP transport showdown > --- > > Key: MRESOLVER-308 > URL: https://issues.apache.org/jira/browse/MRESOLVER-308 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > For HTTP protocol resolver currently provides following transports: > * transport-wagon that uses Maven 2.x Wagon, that among other protocols > supports HTTP/1.1 as well > * transport-http that uses directly Apache HttpClient 4.x supporting > HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all > of remote repositories emit those in headers, sparing one HTTP round-trip) > As we saw, is very easy to outperform these as: > * Maven Central supports HTTP/1.1 but also HTTP/2 > * HTTP/3 is on the way as well > An experiment involving Jetty Client far outperformed both of existing > transports, most probably due HTTP/2 support. > So, clients we should consider: > * Jetty Client > * OkHTTP > * Java 11 HttpClient > Point is, to invest into something that (ideally) transparently supports > HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be > transparently supported (Jetty 12 works on that). We could then simply > compare these implementations, count in pros and cons, and decide where we > want to go, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-303) Make checksum detection reusable
[ https://issues.apache.org/jira/browse/MRESOLVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-303: -- Issue Type: Improvement (was: New Feature) > Make checksum detection reusable > > > Key: MRESOLVER-303 > URL: https://issues.apache.org/jira/browse/MRESOLVER-303 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.3 > > > As currently it is confined into M2 layout implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #65: [MWRAPPER-80] support maven-mvnd
slawekjaranowski commented on PR #65: URL: https://github.com/apache/maven-wrapper/pull/65#issuecomment-1363016541 please also add IT test - to see how it works What with additional task per OS, like for macOs `xattr -r -d ...`? https://github.com/apache/maven-mvnd#install-manually -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-80) Support maven-mvnd as a maven distribution
[ https://issues.apache.org/jira/browse/MWRAPPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651328#comment-17651328 ] ASF GitHub Bot commented on MWRAPPER-80: slawekjaranowski commented on PR #65: URL: https://github.com/apache/maven-wrapper/pull/65#issuecomment-1363016541 please also add IT test - to see how it works What with additional task per OS, like for macOs `xattr -r -d ...`? https://github.com/apache/maven-mvnd#install-manually > Support maven-mvnd as a maven distribution > -- > > Key: MWRAPPER-80 > URL: https://issues.apache.org/jira/browse/MWRAPPER-80 > Project: Maven Wrapper > Issue Type: New Feature > Components: Maven Wrapper Scripts >Reporter: James Z.M. Gao >Priority: Major > > Here is a proposal method to integrate maven-mvnd. > When set distributionUrl to a maven-mvnd downloading url, the wrapper should > distinguish then download/install/run the maven-mvnd on the fly. The script > should take own the os/hardware detecting to select a proper native version. > For example: > * manual select platform: > distributionUrl=[https://downloads.apache.org/maven/mvnd/0.8.2/maven-mvnd-0.8.2-darwin-amd64.zip] > * auto select platform: > distributionUrl=[https://downloads.apache.org/maven/mvnd/0.8.2/maven-mvnd-0.8.2-bin.zip] > In the auto mode, the script can select the real platform via the result of > "uname -a", or fallback to the pure java version for unknown platform. For > `distributionSha256Sum`, we also need new pattern to support multiple > checksum, such as > > * distributionSha256Sum=darwin-aarch64:111;linux-amd64:222 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #71: [MWRAPPER-85] mention distributionType
slawekjaranowski commented on PR #71: URL: https://github.com/apache/maven-wrapper/pull/71#issuecomment-1363036380 What about: https://github.com/apache/maven-wrapper/blob/master/maven-wrapper-plugin/src/site/markdown/usage.md There is descriptions about `Distribution Types` -- 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] (MWRAPPER-85) Docs do not mention distributionType for MavenWrapperDownloader.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651331#comment-17651331 ] ASF GitHub Bot commented on MWRAPPER-85: slawekjaranowski commented on PR #71: URL: https://github.com/apache/maven-wrapper/pull/71#issuecomment-1363036380 What about: https://github.com/apache/maven-wrapper/blob/master/maven-wrapper-plugin/src/site/markdown/usage.md There is descriptions about `Distribution Types` > Docs do not mention distributionType for MavenWrapperDownloader.jar > --- > > Key: MWRAPPER-85 > URL: https://issues.apache.org/jira/browse/MWRAPPER-85 > Project: Maven Wrapper > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Benjamin Marwell >Assignee: Benjamin Marwell >Priority: Major > Labels: Documentation > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] pzygielo commented on pull request #274: Remove unused local variable
pzygielo commented on PR #274: URL: https://github.com/apache/maven-dependency-plugin/pull/274#issuecomment-1363119720 May I ask for review, please? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] andpab opened a new pull request, #587: [SUREFIRE-2101] JUnit5 console reporting: Fall back to class name
andpab opened a new pull request, #587: URL: https://github.com/apache/maven-surefire/pull/587 If phrased console reporting is active, but no @DisplayName annotation is set, fall back to using the class name in console output Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] andpab commented on pull request #549: [SUREFIRE-2101] - Fixes 'null' phrased test names with JUnit5 without @DisplayName
andpab commented on PR #549: URL: https://github.com/apache/maven-surefire/pull/549#issuecomment-1363180381 This pull request fixes the issue for the JUnit5StatelessTestsetInfoReporter, but not for the JUnit5ConsoleOutputReporter. You can see that in the output of the JUnitPlatformEnginesIT#testJupiterEngineWithDisplayNames. It still has "Running null" in it with your fix. The reason it doesn't work there is that you adjusted the behaviour for the CategorizedReportEntry and the WrappedReportEntry, but not for the SimpleReportEntry. I've made an alternative pull request #587 that fixes it in a single place, the TestSetStats class. I think that's more robust. -- 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] (SUREFIRE-2101) Phrased test names with missing @DisplayName result in a "null" test name
[
https://issues.apache.org/jira/browse/SUREFIRE-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651361#comment-17651361
]
Andreas Pabst commented on SUREFIRE-2101:
-
The PR #549 does not fix the issue completely.
I have opened an alternative PR #587 that fixes it completely.
> Phrased test names with missing @DisplayName result in a "null" test name
> -
>
> Key: SUREFIRE-2101
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2101
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M7
> Environment: All platforms
>Reporter: Ashley Scopes
>Priority: Minor
> Attachments: example-reproduction.png
>
>
> If I enable phrased test naming in config, and then write a test such as the
> following:
> {code:java}
> // Note no @DisplayName("...")
> class SomeTest {
> void fooHasThreeCharacters() {
> assertThat(foo).hasSize(3);
> }
> }
> {code}
> ...then the console reports will contain a null name rather than something
> meaningful.
> I am proposing that when this phrased name is unavailable, Surefire should
> fall back to the original test name that would have been provided if phrased
> naming was disabled. The reasoning behind this is that showing an unformatted
> class name is more useful to the developer reading Maven logs than just the
> phrase {{null}}.
> !example-reproduction.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
sultan commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1363198158 > As far as I understand now this is a change in behavior? If so, I cannot apply to 3.8.x because it is not a bugfix. Is it? still a bug fix but i am ok to have it only in Major update 4.0 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651363#comment-17651363
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363198158
> As far as I understand now this is a change in behavior? If so, I cannot
apply to 3.8.x because it is not a bugfix. Is it?
still a bug fix but i am ok to have it only in Major update 4.0
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1363208646 Let me have a fresh look at this tomorrow. -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651367#comment-17651367
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363208646
Let me have a fresh look at this tomorrow.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo merged pull request #176: Assorted minor FAQ edits
elharo merged PR #176: URL: https://github.com/apache/maven-javadoc-plugin/pull/176 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] andpab commented on pull request #564: [SUREFIRE-2032] Fix test count when using @Disabled at class level
andpab commented on PR #564:
URL: https://github.com/apache/maven-surefire/pull/564#issuecomment-1363233419
I can confirm that this PR fixes the issue for the setup of the original
reporter at least - although I had to modify the setup slightly, making the
abstract class an inner class, making the implementations non-static and adding
`@Nested`:
```java
package surefire2032;
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
public class Test1 {
@Tag("red")
@Nested
public class RedTest extends TagTest {
}
@Disabled
@Tag("orange")
@Nested
public class OrangeTest extends TagTest {
}
abstract class TagTest {
@Test
public void test1() {
// Do Nothing
}
@Test
public void test2() {
// Do Nothing
}
}
}
```
Console output:
```
[INFO] Running surefire2032.Test1
[INFO] Running surefire2032.Test1$OrangeTest
[WARNING] Tests run: 2, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
0.008 s - in surefire2032.Test1$OrangeTest
[INFO] Running surefire2032.Test1$RedTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023
s - in surefire2032.Test1$RedTest
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042
s - in surefire2032.Test1
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 2
```
XML output:
```
$ cat target/surefire-reports/TEST-surefire2032.Test1\$OrangeTest.xml
http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd";
version="3.0" name="surefire2032.Test1$OrangeTest" time="0.008" tests="2"
errors="0" skipped="2" failures="0">
$ cat target/surefire-reports/TEST-surefire2032.Test1\$RedTest.xml
http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd";
version="3.0" name="surefire2032.Test1$RedTest" time="0.023" tests="2"
errors="0" skipped="0" failures="0">
...
```
$ cat target/surefire-reports/TEST-surefire2032.Test1.xml
http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd";
version="3.0" name="surefire2032.Test1" time="0.046" tests="0" errors="0"
skipped="0" failures="0">
...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-javadoc-plugin] elharo merged pull request #172: Clean up language and update URLs
elharo merged PR #172: URL: https://github.com/apache/maven-javadoc-plugin/pull/172 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] sultan commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
sultan commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1363244583 > Let me have a fresh look at this tomorrow. yes no hurry, the Maven docs used to tell that all other qualifiers were considered later than release, and as of now: lesser than release. if the spec was in error but require a change then its a major update. what i wonder if its also the same for the dot/hyphen change and need revert 3.8 and 3.9 so the fix is only on 4.0 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651388#comment-17651388
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363244583
> Let me have a fresh look at this tomorrow.
yes no hurry,
the Maven docs used to tell that all other qualifiers were considered later
than release, and as of now: lesser than release. if the spec was in error but
require a change then its a major update.
what i wonder if its also the same for the dot/hyphen change and need revert
3.8 and 3.9 so the fix is only on 4.0
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
michael-o commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1363261723 > > Let me have a fresh look at this tomorrow. > > yes no hurry, > > the Maven docs used to tell that all other qualifiers were considered later than release, and as of now: lesser than release. if the spec was not in error but require a change then its a major update. Will check that. > what i wonder if its also the same for the dot/hyphen change and need revert 3.8 and 3.9 so the fix is only on 4.0 (the more i think the more i'm tempted to say yes) Why? The docs say: else ".qualifier" = "-qualifier" < "-number" < ".number" so `.X` and `-X` are equal and this is what your fix does. It aligns an inconsistency with the specs/docs. -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651396#comment-17651396
]
ASF GitHub Bot commented on MNG-7559:
-
michael-o commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1363261723
> > Let me have a fresh look at this tomorrow.
>
> yes no hurry,
>
> the Maven docs used to tell that all other qualifiers were considered
later than release, and as of now: lesser than release. if the spec was not in
error but require a change then its a major update.
Will check that.
> what i wonder if its also the same for the dot/hyphen change and need
revert 3.8 and 3.9 so the fix is only on 4.0 (the more i think the more i'm
tempted to say yes)
Why? The docs say:
else ".qualifier" = "-qualifier" < "-number" < ".number"
so `.X` and `-X` are equal and this is what your fix does. It aligns an
inconsistency with the specs/docs.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] mthmulders commented on issue #759: NullPointerException
mthmulders commented on issue #759: URL: https://github.com/apache/maven-mvnd/issues/759#issuecomment-1363299539 @marcphilipp, could this be an issue in the Gradle Enterprise Maven extension? In #725, I saw you posted a note that the Gradle team is currently working on making the extension compatible with the Maven Daemon. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski opened a new pull request, #199: Add test for confirmation of failed bannedPlugins
slawekjaranowski opened a new pull request, #199: URL: https://github.com/apache/maven-enforcer/pull/199 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
