[GitHub] [maven-enforcer] KroArtem commented on pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
KroArtem commented on pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#issuecomment-784860238 Based on a discussion in JIRA ticket, this PR should be reworked to support either excludes or includes, not both at the same time. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289720#comment-17289720 ] Krosheninnikov Artem commented on MENFORCER-376: [~jbennett2091], thanks for your input. I did current implementation as you described it in the first sentence. It indeed sounds counter-intuitive in a case with specific vendors. It's also good to get your reaction as PR was more or less reviewed could have reached master. I'll rework the rule to support either excludes or includes, not both. > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Major > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #93: Bump wagon.version from 3.4.2 to 3.4.3
dependabot[bot] opened a new pull request #93: URL: https://github.com/apache/maven-indexer/pull/93 Bumps `wagon.version` from 3.4.2 to 3.4.3. Updates `wagon-provider-api` from 3.4.2 to 3.4.3 Commits https://github.com/apache/maven-wagon/commit/3f5ee7ede47d462758918433144fc20075333a9b;>3f5ee7e [maven-release-plugin] prepare release wagon-3.4.3 https://github.com/apache/maven-wagon/commit/5c73c031758483e0424716bb414c72bb64183546;>5c73c03 [WAGON-609] Upgrade transitive Commons Codec to 1.15 https://github.com/apache/maven-wagon/commit/855c5b46db722b99b8bdc54deaa92692c72b60b7;>855c5b4 [WAGON-607] Upgrade HttpCore to 4.4.14 https://github.com/apache/maven-wagon/commit/e460cd2a7b2221e2dd0914d6c59eb27eeb4ba53c;>e460cd2 [WAGON-608] Upgrade HttpClient to 4.5.13 https://github.com/apache/maven-wagon/commit/aede84b33addb287944a56c7ec3913955909d0f6;>aede84b [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-wagon/compare/wagon-3.4.2...wagon-3.4.3;>compare view Updates `wagon-http` from 3.4.2 to 3.4.3 Updates `wagon-http-lightweight` from 3.4.2 to 3.4.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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request #128: Bump wagon-http-lightweight from 3.4.0 to 3.4.3
dependabot[bot] opened a new pull request #128: URL: https://github.com/apache/maven-dependency-plugin/pull/128 Bumps wagon-http-lightweight from 3.4.0 to 3.4.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 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-376) Add support for excludes/includes in requireJavaVendor rule
[ https://issues.apache.org/jira/browse/MENFORCER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289544#comment-17289544 ] Jeffrey Bennett commented on MENFORCER-376: --- The normal case for both an include and exclude being present would be something like include-a-directory but exclude-file-in-directory. In that scenario, include and exclude make sense as they operate like an all-but-this-one complement to each other. That said, such a scenario does not exist here. The vendors listed are specific ones. In short, should be either includes or excludes but not both. If you have either an include, or an exclude, or neither, it's pretty straight forward. On Sun, Jan 24, 2021, 9:45 AM Krosheninnikov Artem (Jira) > Add support for excludes/includes in requireJavaVendor rule > --- > > Key: MENFORCER-376 > URL: https://issues.apache.org/jira/browse/MENFORCER-376 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Major > > There was a suggestion here [1] to add includes/excludes support in > requireJavaVendor rule. Right now it's not clear how it would work if you > define the same vendor name in exclude and include lists but implementation > can be more or less copied from BannedDependencies rule. > [1] > https://issues.apache.org/jira/browse/MENFORCER-338?focusedCommentId=17169044=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17169044 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7012) Intermittent java.lang.IllegalStateException - entry has not been leased from this pool
[
https://issues.apache.org/jira/browse/MNG-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289536#comment-17289536
]
Frank Rachel commented on MNG-7012:
---
Here is an update of the project.
https://docs.google.com/document/d/e/2PACX-1vRomof7_P-37Z_2EOL63N4yPTAE6Z3mI1F21i8BxVPMuywoSe4FZ6WlN2QeFnPUQhwWnyLo0WRuzmW-/pub
> Intermittent java.lang.IllegalStateException - entry has not been leased from
> this pool
> ---
>
> Key: MNG-7012
> URL: https://issues.apache.org/jira/browse/MNG-7012
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.0
> Environment: Docker (debian:buster as the parent)
>Reporter: Frank Rachel
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> We are sporadically getting this error:
> {code:java}
> 2020:11:03-02:39:51 [WARNING] Failed to load provider from:
> org.codehaus.gmaven.runtime.loader.artifact.ArtifactProviderLoader@46256128
> org.apache.maven.artifact.resolver.ArtifactResolutionException: Could not
> transfer artifact jline:jline:jar:0.9.94 from/to internal-nexus
> (http://ml-pecb-dk01.alipacn.com:50005/repository/alip-repo/): Entry
> [id:541][route:{}->http://ml-pecb-dk01.alipacn.com:50005][state:null] has not
> been leased from this pool
> jline:jline:jar:0.9.94{code}
> in our builds when download artifact from our Nexus repo. This happened under
> 3.5.4, and stil under 3.6.0 (we can't yet upgrade to 3.6.3, but will be able
> to soon).
> It's not always on the same artifact as the exception. This seems to happen
> for about 10% of our builds.. we just re-run it and most of the times it then
> works.
> It also didn't seem to happen when we were using Artifactory (an old version)
> instead of Nexus, though not sure that's related since a lot of other things
> changed at the same time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-447) Unable to compile modularized test for a multi-version jar that is not a java module by default
[
https://issues.apache.org/jira/browse/MCOMPILER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289490#comment-17289490
]
Claudio Corsi commented on MCOMPILER-447:
-
[~bmarwell]
No worries, I looked at the aforementioned link and gave it a try. I was able
to use that technique but it seems wrong that someone would have to go through
all of that trouble to create a multi-version jar file. Especially one that is
a combination like the one that I am trying to create/use. The first part of
this first will remove the need to add such a configuration within the pom
file. It would make the pom file cleaner and more like what is expected.
As for a use-case, you can take the added pom file that is part of the
MCOMPLIER-447 integration test. To reproduce this case, you only would need to
use the compile-java-9 and test-compile-java-9 executions at:
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L57
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L83
To not reproduce the other issue mentioned in this issue. You need to comment
out the Logger.getLogger call within the Test.java file at
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/src/test/test9/org/bar/Test.java#L29
On Monday, December 21, 2020, 5:10:01 PM EST, Benjamin Marwell (Jira)
wrote:
[
https://issues.apache.org/jira/browse/MCOMPILER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253146#comment-17253146
]
Benjamin Marwell commented on MCOMPILER-447:
[~ccorsi]
Sorry that I just know realized what you actually meant in this issue:
{quote}The following changes resolves two different issues. The first is the
case that
the we are creating a multi-version jar file that by default is not modularized.
{quote}
There is no need to do such a thing. A
{color:#0747a6}{{module-info.class}}{color} in the root folder will be ignored
by Java 7 and Java 8. See the [second example
here|https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html].
{quote}a multi-version jar file that by default is not modularized.
{quote}
What is the use case here?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
> Unable to compile modularized test for a multi-version jar that is not a java
> module by default
> ---
>
> Key: MCOMPILER-447
> URL: https://issues.apache.org/jira/browse/MCOMPILER-447
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Claudio Corsi
>Priority: Blocker
>
> I have a single module project that is creating a mult-version jar file. By
> default the multi-version jar is not a java module because it is being built
> for jdk 7 or newer. The multi-version jar does contain a java module
> definition within the /META-INF/versions/9 directory. I am trying to create
> a integration test that uses the java module of the code. When I tried
> building the module tests I got the UnsupportedOperationException with the
> message:
>
> Can't compile test sources when main sources are missing a module descriptor
>
> The issue was that the main module does not contain a module descriptor but
> the test does contain a module descriptor.
>
> I then forked a copy of the maven compiler plugin. I created an integration
> test and was able to fix this issue. The issue was that I needed to find the
> latest version of the java-module for the module generated multi-version jar
> file. This because the module descriptor and was added to the javac command.
>
> I then tried to build my test source again and this time it stated that it
> was not able to find a class because it is part of a jar file that does not
> contain any java module definition. I updated the integration test and was
> able to add another fix to the forked copy that resolved that issue. The
> issue was that all non-java-module jar files should be included as part of
> the class path. They were all being included as part of the module path.
>
> I then used the fixed jar file to build my project and it failed again
> because of it accessing a unnamed module. I had to finally update my pom to
> include a --add-reads command line option. I will not try to add a fix to
> this issue since this issue has a workaround unlike the other two that didn't.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MENFORCER-380) Fix maven assembly links
[ https://issues.apache.org/jira/browse/MENFORCER-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MENFORCER-380. -- Resolution: Fixed > Fix maven assembly links > > > Key: MENFORCER-380 > URL: https://issues.apache.org/jira/browse/MENFORCER-380 > Project: Maven Enforcer Plugin > Issue Type: Task > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] slachiewicz merged pull request #39: Bump mockito-core from 3.7.7 to 3.8.0
slachiewicz merged pull request #39: URL: https://github.com/apache/maven-jlink-plugin/pull/39 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-380) Fix maven assembly links
[ https://issues.apache.org/jira/browse/MENFORCER-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289256#comment-17289256 ] Hudson commented on MENFORCER-380: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-enforcer » master #42 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/42/ > Fix maven assembly links > > > Key: MENFORCER-380 > URL: https://issues.apache.org/jira/browse/MENFORCER-380 > Project: Maven Enforcer Plugin > Issue Type: Task > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] slachiewicz merged pull request #91: [MENFORCER-380] - update assembly links
slachiewicz merged pull request #91: URL: https://github.com/apache/maven-enforcer/pull/91 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MENFORCER-380) Fix maven assembly links
[ https://issues.apache.org/jira/browse/MENFORCER-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MENFORCER-380: -- Assignee: Sylwester Lachiewicz > Fix maven assembly links > > > Key: MENFORCER-380 > URL: https://issues.apache.org/jira/browse/MENFORCER-380 > Project: Maven Enforcer Plugin > Issue Type: Task > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-380) Fix maven assembly links
[ https://issues.apache.org/jira/browse/MENFORCER-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-380: --- Fix Version/s: 3.0.0-M4 3.0.0 > Fix maven assembly links > > > Key: MENFORCER-380 > URL: https://issues.apache.org/jira/browse/MENFORCER-380 > Project: Maven Enforcer Plugin > Issue Type: Task > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] KroArtem commented on pull request #91: [MENFORCER-380] - update assembly links
KroArtem commented on pull request #91: URL: https://github.com/apache/maven-enforcer/pull/91#issuecomment-784330107 @slachiewicz , wdyt about merging this one? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] KroArtem commented on pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
KroArtem commented on pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#issuecomment-784309551 @hboutemy , I see that you're also requested for a review, do you have any review comments? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] KroArtem commented on a change in pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
KroArtem commented on a change in pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#discussion_r581165543 ## File path: enforcer-rules/src/site/apt/requireJavaVendor.apt.vm ## @@ -53,7 +56,13 @@ Require Java Vendor - AdoptOpenJDK + +Pivotal Review comment: These are the names I took from jdk.dev My current mvn -v returns the following: ``` Java version: 15.0.1, vendor: N/A, runtime: /usr/local/Cellar/openjdk/15.0.1/libexec/openjdk.jdk/Contents/Home ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] elharo commented on pull request #75: Remove guava dependency from indexer-core
elharo commented on pull request #75: URL: https://github.com/apache/maven-indexer/pull/75#issuecomment-784208871 Build still fails: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-indexer/job/guava/19/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] elharo commented on pull request #75: Remove guava dependency from indexer-core
elharo commented on pull request #75: URL: https://github.com/apache/maven-indexer/pull/75#issuecomment-784169634 The builds expire after some period of time. I'll have to run this through again. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7106) VersionRange produces a version range that is incompatible with itself
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288963#comment-17288963
]
Michael Osipov commented on MNG-7106:
-
This sounds valid and inconsistent.
> VersionRange produces a version range that is incompatible with itself
> --
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Priority: Minor
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-784020330 Thanks for the ping. Will pick up again during this week. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
