[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280074#comment-17280074
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/6/21, 4:07 AM:
[~tibordigana], no-one has signed up for this ticket yet, so I hope it it OK to
ask you if this is on your radar for M6. Some feedback regarding whether or not
you can reproduce the issue with the sample project I created especially upon
your request. I want this thing to be ready for reproduction and fixing before
you tackle it. If there is anything I can or need to do before you can start
working, I would like to use the waiting time until then in order to make it
ready for you to start and get it off the table as smoothly and quickly as
possible.
was (Author: kriegaex):
[~tibordigana], no-one has signed up for this ticket yet, so I hope it it OK to
ask you if this is on your radar for M6. Some feedback regarding whethet or not
you can reproduce the issue with the sample project I created especially upon
your request. I want this thing to be ready for reproduction and fixing before
you tackle it. if there is anything I can or need to do before you can start
this one, I would like to use the waiting time until then in order to make it
ready for you to start working on it and get it off the table as smoothly and
quickly as possible.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280074#comment-17280074
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
[~tibordigana], no-one has been signed up for this ticket yet, so I hope it it
OK to ask you if this is on your radar for M6. Some feedback regarding whethet
or not you can reproduce the issue with the sample project I created especially
upon your request. I want this thing to be ready for reproduction and fixing
before you tackle it. if there is anything I can or need to do before you can
start this one, I would like to use the waiting time until then in order to
make it ready for you to start working on it and get it off the table as
smoothly and quickly as possible.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280074#comment-17280074
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/6/21, 4:06 AM:
[~tibordigana], no-one has signed up for this ticket yet, so I hope it it OK to
ask you if this is on your radar for M6. Some feedback regarding whethet or not
you can reproduce the issue with the sample project I created especially upon
your request. I want this thing to be ready for reproduction and fixing before
you tackle it. if there is anything I can or need to do before you can start
this one, I would like to use the waiting time until then in order to make it
ready for you to start working on it and get it off the table as smoothly and
quickly as possible.
was (Author: kriegaex):
[~tibordigana], no-one has been signed up for this ticket yet, so I hope it it
OK to ask you if this is on your radar for M6. Some feedback regarding whethet
or not you can reproduce the issue with the sample project I created especially
upon your request. I want this thing to be ready for reproduction and fixing
before you tackle it. if there is anything I can or need to do before you can
start this one, I would like to use the waiting time until then in order to
make it ready for you to start working on it and get it off the table as
smoothly and quickly as possible.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280026#comment-17280026
]
Hudson commented on MNG-6772:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #10
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/10/
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7029) Remove super POM release profile
[ https://issues.apache.org/jira/browse/MNG-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280025#comment-17280025 ] Hudson commented on MNG-7029: - Build unstable in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #10 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/10/ > Remove super POM release profile > > > Key: MNG-7029 > URL: https://issues.apache.org/jira/browse/MNG-7029 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The release profile has been deprecated for a long time with scheduled for > removal. This ticket formally represents this task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280024#comment-17280024
]
Hudson commented on MNG-7051:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #10
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/10/
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7049) Version range resolution downloads all poms, not just the highest version
[ https://issues.apache.org/jira/browse/MNG-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280006#comment-17280006 ] Eli Smaga commented on MNG-7049: [~michael-o] Can you point me to where in the Maven code base the downloading of all the pom files is being done, and also what action in the DefaultVersionRangeResolver is triggering that to happen? Sorry, but I am having hard time figuring that out. Is there a functional reason that Maven downloads all of those pom files? I'm asking because I am curious if we disable that whether it would cause any downstream issues? Do you know of a way to disable that from happening with out having to build a custom version of Maven or some other work around? [~mnk] Did you find a solution or a way to work around this? > Version range resolution downloads all poms, not just the highest version > - > > Key: MNG-7049 > URL: https://issues.apache.org/jira/browse/MNG-7049 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Moti Nisenson-Ken >Priority: Major > > When specifying a version range for a dependency, maven will download and try > to resolve all poms in that range which satisfy the range. The usage however > is only to use the highestVersion. This causes two issues: > # Performance - it's downloading numerous poms that aren't needed. > # Fragility - if the version range covers any "bad" poms, then the build > will fail. For example, consider that for a specific version, the parent of a > pom is not present in the repository. This is enough to fail any build with a > version range covering that specific version, as the range resolution stage > will not complete. This is particularly harmful when that version would not > be selected as the highest, anyway. > Recommend to have a system property to control the desired behavior - it > should be possible to short-circuit loading all the versions and to just to > load the highest version. > For another user report of this see: > [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRRESOURCES-102) Filtering of non-.vm files
[ https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MRRESOURCES-102: - Fix Version/s: 3.0.0 > Filtering of non-.vm files > -- > > Key: MRRESOURCES-102 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-102 > Project: Maven Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.5 >Reporter: Falko Modler >Priority: Major > Fix For: 3.0.0 > > > It would be a very welcomed addition if the plugin would also filter > non-verlocity (.vm) files. > See also: MRRESOURCES-83 > Renaming the files in question to *.vm is not an option for me because: > - MRRESOURCES-94 > - the module _providing_ the file(s) also needs them _without_ .vm suffix > (fixing this would require some other plugin) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on pull request #93: [MRESOLVER-159] Mark components as Singletons
michael-o commented on pull request #93: URL: https://github.com/apache/maven-resolver/pull/93#issuecomment-774271735 > @michael-o Not quite get your question, they are in that order (singleton, named) Apologies, I mislooked. Will test. 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] [Closed] (MSCRIPTING-3) Illegal reflective access warnings when using groovy engine on Java 11
[
https://issues.apache.org/jira/browse/MSCRIPTING-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSCRIPTING-3.
---
Assignee: Robert Scholte
Resolution: Cannot Reproduce
Okay, just will add one more thing: the plugin itself doesn't come with any
script engine: the user needs to add it as a dependency. In such case, it is
the developers responsibility to keep the script engine up to date (e.g.
groovy-jsr223)
> Illegal reflective access warnings when using groovy engine on Java 11
> --
>
> Key: MSCRIPTING-3
> URL: https://issues.apache.org/jira/browse/MSCRIPTING-3
> Project: Maven Scripting
> Issue Type: Improvement
>Reporter: Raymond Augé
>Assignee: Robert Scholte
>Priority: Minor
>
> When run in a build using Java 11 (didn't test java 9,10) I get the warning:
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1
> (file:[snip]/.m2/repository/org/codehaus/groovy/groovy/2.5.5/groovy-2.5.5.jar)
> to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.vmplugin.v7.Java7$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> To be fair this is due to https://issues.apache.org/jira/browse/GROOVY-8339
> So _this_ issue is really a placeholder that at some point may require some
> work against a new version of groovy.
> Of if you think it's really just _blame upstream_ case, then this can be
> closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSCRIPTING-3) Illegal reflective access warnings when using groovy engine on Java 11
[
https://issues.apache.org/jira/browse/MSCRIPTING-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279939#comment-17279939
]
Raymond Augé commented on MSCRIPTING-3:
---
Hey Robert, I've not used this in a while and don't think I have an env setup
to check it. So if you're confident that it's no longer an issue then I'm
agreeable to closing the issue. I can always open it up again if it comes
along. :)
> Illegal reflective access warnings when using groovy engine on Java 11
> --
>
> Key: MSCRIPTING-3
> URL: https://issues.apache.org/jira/browse/MSCRIPTING-3
> Project: Maven Scripting
> Issue Type: Improvement
>Reporter: Raymond Augé
>Priority: Minor
>
> When run in a build using Java 11 (didn't test java 9,10) I get the warning:
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1
> (file:[snip]/.m2/repository/org/codehaus/groovy/groovy/2.5.5/groovy-2.5.5.jar)
> to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.vmplugin.v7.Java7$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> To be fair this is due to https://issues.apache.org/jira/browse/GROOVY-8339
> So _this_ issue is really a placeholder that at some point may require some
> work against a new version of groovy.
> Of if you think it's really just _blame upstream_ case, then this can be
> closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MARTIFACT-11) multi-module: copy also aggregate buildinfo.compare to root target
[ https://issues.apache.org/jira/browse/MARTIFACT-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279921#comment-17279921 ] Hudson commented on MARTIFACT-11: - Build succeeded in Jenkins: Maven » Maven TLP » maven-artifact-plugin » master #44 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-artifact-plugin/job/master/44/ > multi-module: copy also aggregate buildinfo.compare to root target > -- > > Key: MARTIFACT-11 > URL: https://issues.apache.org/jira/browse/MARTIFACT-11 > Project: Maven Artifact Plugin > Issue Type: New Feature >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.0.0 > > > aggregate buildinfo copied in MARTIFACT-8 > we need also buildinfo.compare -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279882#comment-17279882
]
Hudson commented on MNG-6772:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #8
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/8/
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-379) Update maven-common-artifact-filters to 3.1.1/3.1.2
[ https://issues.apache.org/jira/browse/MENFORCER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279801#comment-17279801 ] Hudson commented on MENFORCER-379: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-enforcer » master #37 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/37/ > Update maven-common-artifact-filters to 3.1.1/3.1.2 > --- > > Key: MENFORCER-379 > URL: https://issues.apache.org/jira/browse/MENFORCER-379 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] cstamas commented on pull request #93: [MRESOLVER-159] Mark components as Singletons
cstamas commented on pull request #93: URL: https://github.com/apache/maven-resolver/pull/93#issuecomment-774121457 @michael-o Not quite get your question, they are in that order (singleton, named) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] oehme commented on pull request #333: Add failOnFlakeCount option
oehme commented on pull request #333: URL: https://github.com/apache/maven-surefire/pull/333#issuecomment-774097056 If you want I can send another PR, otherwise I'll let you take care of 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1459) mvn+java7 and POM with toolchains targeting java8 fail in surefire plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279737#comment-17279737 ] Markus Kopp commented on SUREFIRE-1459: --- This also affects java8 configured in path and java11 configured with toolchain plugin and on Linux. > mvn+java7 and POM with toolchains targeting java8 fail in surefire plugin > - > > Key: SUREFIRE-1459 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1459 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 2.20.1 > Environment: Maven 3.3.9 started with JDK 7 > (on Windows Server 2012) >Reporter: Rüdiger Groß-Hardt >Assignee: Tibor Digana >Priority: Major > Labels: toolchains > Attachments: run-with-errors.txt, surefire-1459.zip > > > We compile and test with a POM using a toolchain configuration targeting JDK > 8. Maven itself runs with JDK 7. If we run tests with the > maven-surefire-plugin and forkCount=1 and reuseForks=false the build fails > with > _java.lang.UnsupportedClassVersionError: SomeTestClass : Unsupported > major.minor version 52.0_ > If we set reuseForks=true, it builds fine. Other combinations seem to fail, > if the plugin code running in the JDK 7 context presumably needs to use > reflections to enumerate test classes. > As newbies to toolchains, we were assuming, that toolchains enabled us to > effectively decouple the JDK version used to run maven from the JDK version > used to run the tests. > This problem took us quite some time to solve. As an improvement I would > suggest a meaningful warning or error message stating that the surefire > plugin must be run with a JDK version higher than or equal to the version of > the target JDK from the toolchain configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSCRIPTING-3) Illegal reflective access warnings when using groovy engine on Java 11
[
https://issues.apache.org/jira/browse/MSCRIPTING-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279730#comment-17279730
]
Robert Scholte commented on MSCRIPTING-3:
-
[~rotty3000] I don't see this exception (anymore) when I build this project.
Can you confirm?
> Illegal reflective access warnings when using groovy engine on Java 11
> --
>
> Key: MSCRIPTING-3
> URL: https://issues.apache.org/jira/browse/MSCRIPTING-3
> Project: Maven Scripting
> Issue Type: Improvement
>Reporter: Raymond Augé
>Priority: Minor
>
> When run in a build using Java 11 (didn't test java 9,10) I get the warning:
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1
> (file:[snip]/.m2/repository/org/codehaus/groovy/groovy/2.5.5/groovy-2.5.5.jar)
> to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.vmplugin.v7.Java7$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> To be fair this is due to https://issues.apache.org/jira/browse/GROOVY-8339
> So _this_ issue is really a placeholder that at some point may require some
> work against a new version of groovy.
> Of if you think it's really just _blame upstream_ case, then this can be
> closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSCRIPTING-2) Update parent to 33 and maven-shared-utils to 3.2.1
[ https://issues.apache.org/jira/browse/MSCRIPTING-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSCRIPTING-2. --- Fix Version/s: 3.0.0 Resolution: Fixed Fixed in [607f9bb24f6a12f2eea54ca4300d3f660c5aad8f|https://gitbox.apache.org/repos/asf?p=maven-scripting-plugin.git;a=commit;h=607f9bb24f6a12f2eea54ca4300d3f660c5aad8f] > Update parent to 33 and maven-shared-utils to 3.2.1 > --- > > Key: MSCRIPTING-2 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-2 > Project: Maven Scripting > Issue Type: Dependency upgrade >Reporter: Enrico Olivelli >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSCRIPTING-4) make build Reproducible
[ https://issues.apache.org/jira/browse/MSCRIPTING-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSCRIPTING-4. --- Fix Version/s: 3.0.0 Resolution: Fixed Fixed in [d47a51615d997b0d99c5f5b350e558e4b9abc708|https://gitbox.apache.org/repos/asf?p=maven-scripting-plugin.git;a=commit;h=d47a51615d997b0d99c5f5b350e558e4b9abc708] > make build Reproducible > --- > > Key: MSCRIPTING-4 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-4 > Project: Maven Scripting > Issue Type: Improvement >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #332: [SUREFIRE-1882] Fix failures when compiled on Java 9+ and run on Java 8
Tibor17 edited a comment on pull request #332: URL: https://github.com/apache/maven-surefire/pull/332#issuecomment-774051665 @kriegaex The Apache changed the politcy and so only people with `apache.org` can be invited via e-mail. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #332: [SUREFIRE-1882] Fix failures when compiled on Java 9+ and run on Java 8
Tibor17 commented on pull request #332: URL: https://github.com/apache/maven-surefire/pull/332#issuecomment-774051665 @kriegaex The Apache changed the politcy and so only people with `apache.org` can be invited. 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] [Updated] (SUREFIRE-1885) Maven is not running any tests called using testng suitexml files in POM
[ https://issues.apache.org/jira/browse/SUREFIRE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1885: - Summary: Maven is not running any tests called using testng suitexml files in POM (was: Maven is not running any tests called using testng suitexml files in POM.xml) > Maven is not running any tests called using testng suitexml files in POM > > > Key: SUREFIRE-1885 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1885 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, TestNG > support >Reporter: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > I have seen this issue many times and always it was a user error because the > file is in wrong place on the file system. This issue improves sanity check > in the plugin and eagerly has to crash the plugin while the file does not > exist and explain the root cause on the console. > https://sqa.stackexchange.com/questions/45946/maven-is-not-running-any-tests-called-using-testng-suitexml-files-in-pom-xml/46714 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7051) Optionally skip non-existing profiles
[
https://issues.apache.org/jira/browse/MNG-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279643#comment-17279643
]
Hudson commented on MNG-7051:
-
Build failed in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/3/
> Optionally skip non-existing profiles
> -
>
> Key: MNG-7051
> URL: https://issues.apache.org/jira/browse/MNG-7051
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Maarten Mulders
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> For Maven 4, the behaviour of the {{-P}} command line option will change:
> * {{-P apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will break.
> * {{-P ?apache-release}} will activate the *apache-release* profile. If such
> a profile cannot be found, the build will continue but log a warning.
> {color:#ff}
> Note that this breaks the current behaviour of Maven 3 in two ways:
> {color}
> # {{-P apache-release}} will currently log a warning and not break the build.
> That behaviour can be restored by adding the {{?}}.
> # A profile that has an identifier that not valid (i.e., contains anything
> else than {{a}} - {{z}}, {{A}} to {{Z}}, {{0}} - {{9}}, {{-}}, {{_}} or
> {{.}}) will break the build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7029) Remove super POM release profile
[ https://issues.apache.org/jira/browse/MNG-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279645#comment-17279645 ] Hudson commented on MNG-7029: - Build failed in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/3/ > Remove super POM release profile > > > Key: MNG-7029 > URL: https://issues.apache.org/jira/browse/MNG-7029 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The release profile has been deprecated for a long time with scheduled for > removal. This ticket formally represents this task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7068) Active dependency management for Google Guice/Guava
[ https://issues.apache.org/jira/browse/MNG-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279644#comment-17279644 ] Hudson commented on MNG-7068: - Build failed in Jenkins: Maven » Maven TLP » maven » revert-MNG-6772 #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/revert-MNG-6772/3/ > Active dependency management for Google Guice/Guava > --- > > Key: MNG-7068 > URL: https://issues.apache.org/jira/browse/MNG-7068 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Boris Unckel >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > The current pom includes com.google.inject:guice with the default transitive > dependency of com.google.guava:guava. Guava has declared several > dependencies, which are not needed at runtime. Only > com.google.guava:failureaccess is needed. > The proposal is first to add com.google.guava:guava to the excludes of guice. > Second guava and failureaccess shall be added as direct dependencies. > This has two advantages: Downstream projects only get the needed dependencies > and the version of guava can be independently set. > The runtime dependencies for Guava are explained in the last section of the > [README|https://github.com/google/guava/tree/v30.1] "Important Warnings" #3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] cstamas opened a new pull request #93: [MRESOLVER-159] Mark components as Singletons
cstamas opened a new pull request #93: URL: https://github.com/apache/maven-resolver/pull/93 When used with SISU, the components were NOT singletons but prototypes, which is not the intent. In Guice module they were properly marked as such. https://issues.apache.org/jira/browse/MRESOLVER-159 PR tested with maven commit eae3074c63dbba24680d7049dc36217323c7d00b maven ITs with maven built above 46fbd48777db99a339668b67c43bf4fce33cd824 Both passes OK 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-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r570874900 ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NoLockSyncContextFactory.java ## @@ -22,39 +22,42 @@ import java.util.Collection; import javax.inject.Named; +import javax.inject.Singleton; import org.eclipse.aether.RepositorySystemSession; import org.eclipse.aether.SyncContext; import org.eclipse.aether.artifact.Artifact; -import org.eclipse.aether.spi.synccontext.SyncContextFactory; import org.eclipse.aether.metadata.Metadata; /** * A factory to create synchronization contexts. This default implementation does not provide any real * synchronization but merely completes the repository system. */ -@Named -public class DefaultSyncContextFactory -implements SyncContextFactory, org.eclipse.aether.impl.SyncContextFactory +@Singleton +@Named( NoLockSyncContextFactory.NAME ) +public class NoLockSyncContextFactory Review comment: kk, will leave it as is 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] michael-o commented on pull request #394: [MNG-7020] Remove Maven 2 WagonExcluder backward compat code
michael-o commented on pull request #394: URL: https://github.com/apache/maven/pull/394#issuecomment-773440336 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] michael-o commented on pull request #418: [MNG-6114] Elements from the global settings should be ordered before…
michael-o commented on pull request #418: URL: https://github.com/apache/maven/pull/418#issuecomment-773440654 @rfscholte Any objections to merge this This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 merged pull request #333: Add failOnFlakeCount option
Tibor17 merged pull request #333: URL: https://github.com/apache/maven-surefire/pull/333 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-773508958 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] rfscholte commented on pull request #394: [MNG-7020] Remove Maven 2 WagonExcluder backward compat code
rfscholte commented on pull request #394: URL: https://github.com/apache/maven/pull/394#issuecomment-773483832 IIRC this triggered a new issue. I'll remove my approval and need to have another look at 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #333: Add failOnFlakeCount option
Tibor17 commented on pull request #333: URL: https://github.com/apache/maven-surefire/pull/333#issuecomment-773630782 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-pdf-plugin] slachiewicz closed pull request #3: [MPDF-92] Require Java 7 at runtime
slachiewicz closed pull request #3: URL: https://github.com/apache/maven-pdf-plugin/pull/3 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-filtering] sebthom commented on pull request #15: [MRESOURCES-268] - Report path of offending file on copy/filter error.
sebthom commented on pull request #15: URL: https://github.com/apache/maven-filtering/pull/15#issuecomment-773855700 I pushed a change since apparently not only checked IOExceptions but also intenral runtime exceptions (e.g. IllegalArgumentExcpetion) are thrown since version 3.2.0 of the maven-resource-plugin when a filtered file has an unexpected encoding. Here is real world example. A submodule of a very large multi-artifact/module enterprise application. Without this PR it have would been very laborious (and maybe impossible for the average developer) to discover the root cause. Before this PR:  After this PR:  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] elharo commented on a change in pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
elharo commented on a change in pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#discussion_r570550213 ## File path: enforcer-rules/src/site/apt/requireJavaVendor.apt.vm ## @@ -53,7 +56,13 @@ Require Java Vendor - AdoptOpenJDK + +Pivotal Review comment: are these the actual vendor names we would see? 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] rfscholte commented on pull request #418: [MNG-6114] Elements from the global settings should be ordered before…
rfscholte commented on pull request #418: URL: https://github.com/apache/maven/pull/418#issuecomment-773482877 @cstamas @stephenc as this is a change in the dependency resolution, you should have a look it this too. 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] elharo commented on pull request #86: [MENFORCER-376] Add excludes/includes functionality to RequireJavaVendor rule
elharo commented on pull request #86: URL: https://github.com/apache/maven-enforcer/pull/86#issuecomment-773597795 Yes, those changes should be in this PR too. 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] michael-o commented on pull request #177: [MNG-6471] during parallel build, ensure to set the thread name to the artifactId
michael-o commented on pull request #177: URL: https://github.com/apache/maven/pull/177#issuecomment-773384411 @rmannibucau Please have a look at the update. 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] michael-o edited a comment on pull request #418: [MNG-6114] Elements from the global settings should be ordered before…
michael-o edited a comment on pull request #418: URL: https://github.com/apache/maven/pull/418#issuecomment-773440654 @rfscholte Any objections to merge this? 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
