[jira] [Commented] (MNG-7825) XML entity in pom cause NPE in MXSerializer during install
[
https://issues.apache.org/jira/browse/MNG-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738913#comment-17738913
]
Slawomir Jaranowski commented on MNG-7825:
--
confirm - works on master
> XML entity in pom cause NPE in MXSerializer during install
> --
>
> Key: MNG-7825
> URL: https://issues.apache.org/jira/browse/MNG-7825
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
>
> When we have a xml entity in project, like:
> {code}
> test < test
> {code}
> we will have:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke "String.length()"
> because "str" is null
> at java.io.Writer.write (Writer.java:278)
> at org.codehaus.plexus.util.xml.pull.MXSerializer.entityRef
> (MXSerializer.java:806)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:81)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:40)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer.transform
> (ConsumerPomArtifactTransformer.java:195)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer$ConsumerPomArtifact.lambda$transformer$1
> (ConsumerPomArtifactTransformer.java:175)
> at org.apache.maven.internal.transformation.OnChangeTransformer.mayUpdate
> (OnChangeTransformer.java:93)
> at org.apache.maven.internal.transformation.OnChangeTransformer.get
> (OnChangeTransformer.java:72)
> at org.apache.maven.internal.transformation.TransformedArtifact.getFile
> (TransformedArtifact.java:76)
> at org.apache.maven.RepositoryUtils.toArtifact (RepositoryUtils.java:159)
> at org.apache.maven.plugins.install.InstallMojo.processProject
> (InstallMojo.java:227)
> at org.apache.maven.plugins.install.InstallMojo.execute
> (InstallMojo.java:144)
> {noformat}
> works in 3.9.3, 4.0.0-alpha-5
> m-install-p - 3.1.1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SUREFIRE-2179.
---
Fix Version/s: 3.x-candidate
Resolution: Fixed
Fixed in
https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.x-candidate
>
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738903#comment-17738903
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin merged PR #667:
URL: https://github.com/apache/maven-surefire/pull/667
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738902#comment-17738902 ] ASF GitHub Bot commented on MNG-7532: - rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1614186284 @slachiewicz if we switch we should just go to JUL IMHO (see the list for details) but not sure it would be for v4, hopefully v5. Anyway, does not change anything to the fact we don't want to show our impl to end users since one feature we provide is the hability to integrator to handle it as they want. All log libs have pitfalls and we can't make everything working (typically there are some cases with some bridge which will fail), so let's stay simple and 1. drop slf4j from consumers view in code, 2. if we need to change current impl move to JUL which enables to be dep free, abstract any impl (several asf projects do like cxf) and work in all integrator env without hacks. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1614186284 @slachiewicz if we switch we should just go to JUL IMHO (see the list for details) but not sure it would be for v4, hopefully v5. Anyway, does not change anything to the fact we don't want to show our impl to end users since one feature we provide is the hability to integrator to handle it as they want. All log libs have pitfalls and we can't make everything working (typically there are some cases with some bridge which will fail), so let's stay simple and 1. drop slf4j from consumers view in code, 2. if we need to change current impl move to JUL which enables to be dep free, abstract any impl (several asf projects do like cxf) and work in all integrator env without hacks. -- 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-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738896#comment-17738896 ] ASF GitHub Bot commented on MNG-7532: - gnodet commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1614177949 > Then we can also think how to support slf4j 1 and 2. More and more libs switch to v2 Afaik, the client api is compatible, if maven exports slf4j 2.x and provides an implementation, client should be fine. See https://www.slf4j.org/faq.html#compatibility > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
gnodet commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1614177949 > Then we can also think how to support slf4j 1 and 2. More and more libs switch to v2 Afaik, the client api is compatible, if maven exports slf4j 2.x and provides an implementation, client should be fine. See https://www.slf4j.org/faq.html#compatibility -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738868#comment-17738868
]
ASF GitHub Bot commented on MRESOLVER-376:
--
caiwei-ebay2 commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614097696
@cstamas
A few questions.
BF patch do considers relocated artifact but does not work for this case,
May I know what's the special thing of this relocation artifact?
From my original implementation, it is like this:
A1 will be relocates to A2, so first we resolve A1, we cache A2's descriptor
with A2's key, next resolve A2, A2 is already there.
This is different with the behavior as you observed.
"it will use RelocatedArtifact (in maven-resolver-provider) as
result.artifact, and BF use this artifact as key. But, this artifact will be
key of relocation target, while the descriptor is the descriptor of original
(relocated) artifact"
Let me try reproduce the issue.
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738828#comment-17738828
]
ASF GitHub Bot commented on MRESOLVER-376:
--
caiwei-ebay2 commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1613935345
@cstamas @snjeza
Looks good to me, thanks for the fix!
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] caiwei-ebay2 commented on pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
caiwei-ebay2 commented on PR #309: URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1613935345 @cstamas @snjeza Looks good to me, thanks for the fix! -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738826#comment-17738826
]
ASF GitHub Bot commented on MRESOLVER-376:
--
snjeza commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1613928729
This PR fixes https://github.com/redhat-developer/vscode-java/issues/3085
and https://issues.apache.org/jira/browse/MRESOLVER-376
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-378) Update parent POM to 40
[ https://issues.apache.org/jira/browse/MRESOLVER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738825#comment-17738825 ] ASF GitHub Bot commented on MRESOLVER-378: -- cstamas commented on PR #310: URL: https://github.com/apache/maven-resolver/pull/310#issuecomment-1613926755 There are plugin entries to be removed, and probably japicmp update > Update parent POM to 40 > --- > > Key: MRESOLVER-378 > URL: https://issues.apache.org/jira/browse/MRESOLVER-378 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > To get all the latest plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7828) Bump guava from 31.1-jre to 32.0.1-jre
[ https://issues.apache.org/jira/browse/MNG-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738808#comment-17738808 ] ASF GitHub Bot commented on MNG-7828: - cstamas commented on PR #1191: URL: https://github.com/apache/maven/pull/1191#issuecomment-1613888356 Maven 3.8.x release will happen if someone comes up with some blocker bug, which i doubt. And I am curious, why not moving to 3.9.x line? > Bump guava from 31.1-jre to 32.0.1-jre > -- > > Key: MNG-7828 > URL: https://issues.apache.org/jira/browse/MNG-7828 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.x-candidate, 4.0.x-candidate >Reporter: Bruno Candido Volpato da Cunha >Priority: Major > > Currently used version is in the range of CVE-2023-2976, which was fixed in > 32.0.0. > > Please check [https://osv.dev/vulnerability/GHSA-7g45-4rm6-3mm3] for more > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1191: [MNG-7828] Bump guava from 30.1-jre to 32.0.1-jre
cstamas commented on PR #1191: URL: https://github.com/apache/maven/pull/1191#issuecomment-1613888356 Maven 3.8.x release will happen if someone comes up with some blocker bug, which i doubt. And I am curious, why not moving to 3.9.x line? -- 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] [Comment Edited] (SCM-798) scm:branch ignores the tagBase parameter, there is no branchBase parameter
[
https://issues.apache.org/jira/browse/SCM-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738804#comment-17738804
]
Clemens Quoß edited comment on SCM-798 at 6/29/23 10:11 PM:
I can pick this one up. It's not that i really have a current issue with this
but i do not like to have jira tickets lying around that could be fixed IMHO.
For this one i would propose this: Rename the tagBase parameter maven-scm wide
to sth. like copyBase or cpBase (maybe someone can come up with a better name -
but i think it would be OK as this parameter is only svn-related and copy is
the action used for tagging and branching in Subversion). With this generic
name this parameter can be used for tag and branch operations.
And then make this parameter also work on the branch goal.
WDYT?
Ah, but this of course breaks maven-release. But never mind. I could take care
of that as well. But that adds an external dependency. Both need to be released
synchroneously.
was (Author: cquoss):
I can pick this one up. It's not that i really have a current issue with this
but i do not like to have jira tickets lying around that could be fixed IMHO.
For this one i would propose this: Rename the tagBase parameter maven-scm wide
to sth. like copyBase or cpBase (maybe someone can come up with a better name -
but i think it would be OK as this parameter is only svn-related and copy is
the action used for tagging and branching in Subversion). With this generic
name this parameter can be used for tag and branch operations.
And then make this parameter also work on the branch goal.
WDYT?
> scm:branch ignores the tagBase parameter, there is no branchBase parameter
> --
>
> Key: SCM-798
> URL: https://issues.apache.org/jira/browse/SCM-798
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin, maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Major
>
> {code}[DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
> configurator -->
> [DEBUG] (f) basedir = /home/acme/gotham/common_ui
> [DEBUG] (f) branch = 2.2/2.2.0
> [DEBUG] (f) connectionType = connection
> [DEBUG] (s) connectionUrl =
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG] (f) developerConnectionUrl =
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG] (f) pushChanges = true
> [DEBUG] (f) remoteBranching = false
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
> [DEBUG] (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
> [DEBUG] -- end configuration --
> [INFO] Final Branch Name: '2.2/2.2.0'
> [INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui && svn
> --non-interactive copy --file /tmp/maven-scm-1267210601.commit .
> svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
> {code}
> I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
> {code}
> if ( !StringUtils.isEmpty( tagBase ) &&
> repository.getProvider().equals( "svn" ) )
> {
> SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
> repository.getProviderRepository();
> svnRepo.setTagBase( tagBase );
> }{code}
> Adding a parallel handling for {{branchBase}} param should be trivial.
> Correcting the documentation is another thing -- the {{tagBase}} parameter is
> present on the base Mojo class even though it's ignored in some goals.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SCM-798) scm:branch ignores the tagBase parameter, there is no branchBase parameter
[
https://issues.apache.org/jira/browse/SCM-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738804#comment-17738804
]
Clemens Quoß commented on SCM-798:
--
I can pick this one up. It's not that i really have a current issue with this
but i do not like to have jira tickets lying around that could be fixed IMHO.
For this one i would propose this: Rename the tagBase parameter maven-scm wide
to sth. like copyBase or cpBase (maybe someone can come up with a better name -
but i think it would be OK as this parameter is only svn-related and copy is
the action used for tagging and branching in Subversion). With this generic
name this parameter can be used for tag and branch operations.
And then make this parameter also work on the branch goal.
WDYT?
> scm:branch ignores the tagBase parameter, there is no branchBase parameter
> --
>
> Key: SCM-798
> URL: https://issues.apache.org/jira/browse/SCM-798
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin, maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Major
>
> {code}[DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic
> configurator -->
> [DEBUG] (f) basedir = /home/acme/gotham/common_ui
> [DEBUG] (f) branch = 2.2/2.2.0
> [DEBUG] (f) connectionType = connection
> [DEBUG] (s) connectionUrl =
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG] (f) developerConnectionUrl =
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG] (f) pushChanges = true
> [DEBUG] (f) remoteBranching = false
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
> [DEBUG] (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
> [DEBUG] -- end configuration --
> [INFO] Final Branch Name: '2.2/2.2.0'
> [INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui && svn
> --non-interactive copy --file /tmp/maven-scm-1267210601.commit .
> svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
> {code}
> I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
> {code}
> if ( !StringUtils.isEmpty( tagBase ) &&
> repository.getProvider().equals( "svn" ) )
> {
> SvnScmProviderRepository svnRepo = (SvnScmProviderRepository)
> repository.getProviderRepository();
> svnRepo.setTagBase( tagBase );
> }{code}
> Adding a parallel handling for {{branchBase}} param should be trivial.
> Correcting the documentation is another thing -- the {{tagBase}} parameter is
> present on the base Mojo class even though it's ignored in some goals.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-377: -- Issue Type: Improvement (was: Task) > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-378) Update parent POM to 40
[ https://issues.apache.org/jira/browse/MRESOLVER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738803#comment-17738803 ] ASF GitHub Bot commented on MRESOLVER-378: -- cstamas opened a new pull request, #310: URL: https://github.com/apache/maven-resolver/pull/310 --- https://issues.apache.org/jira/browse/MRESOLVER-378 > Update parent POM to 40 > --- > > Key: MRESOLVER-378 > URL: https://issues.apache.org/jira/browse/MRESOLVER-378 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > To get all the latest plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-378) Update parent POM to 40
Tamas Cservenak created MRESOLVER-378: - Summary: Update parent POM to 40 Key: MRESOLVER-378 URL: https://issues.apache.org/jira/browse/MRESOLVER-378 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.14 To get all the latest plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738800#comment-17738800
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1613855291
@caiwei-ebay ping
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
cstamas commented on PR #309: URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1613855291 @caiwei-ebay ping -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738798#comment-17738798
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas opened a new pull request, #309:
URL: https://github.com/apache/maven-resolver/pull/309
The code uses Artifact to key (forever during collection) the read artifact
descriptors, but, this is not always what we want.
Example: ArtifactDescriptorReader when reads a relocated artifact, it will
use RelocatedArtifact (in maven-resolver-provider) as result.artifact, and BF
use this artifact as key. But, this artifact will be key of relocation target,
while the descriptor is the descriptor of original (relocated) artifact. As it
gets into (inner) async resolver cache, it will stay there forever. But alas,
we next ask for relocation target decriptor, that as can be seen, use same
(key-wise, or GAV wise) key as the relocated artifact, and nothing happens, as
computeIfAbsent does not compute (as it is present), and we fall into endless
loop.
---
https://issues.apache.org/jira/browse/MRESOLVER-376
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-377) Introduce metadata update policy
[
https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738792#comment-17738792
]
ASF GitHub Bot commented on MRESOLVER-377:
--
cstamas commented on code in PR #308:
URL: https://github.com/apache/maven-resolver/pull/308#discussion_r1247189892
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -94,7 +94,7 @@ public interface RepositorySystemSession {
String getChecksumPolicy();
/**
- * Gets the global update policy. If set, the global update policy
overrides the update policies of the remote
+ * Gets the global data update policy. If set, the global update policy
overrides the update policies of the remote
Review Comment:
IMHO, "data", as we call consequently the other "metadata" everywhere. Yes,
in resolver, "data" is "artifact", but the point is, it does not have to be
only that. Hence I went with generic "data" and "metadata".
> Introduce metadata update policy
>
>
> Key: MRESOLVER-377
> URL: https://issues.apache.org/jira/browse/MRESOLVER-377
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.14
>
>
> Basically double the update policy, from RemoteRepository all way where
> needed, and make Resolver support separate "data" updatePolicy and "metadata"
> updatePolicy.
> Maven does not have to make use of this (setting updatePolicy ==
> metadataUpdatePolicy results in functionality like today, where there is only
> one policy).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #308: [MRESOLVER-377] Introduce metadataUpdatePolicy
cstamas commented on code in PR #308:
URL: https://github.com/apache/maven-resolver/pull/308#discussion_r1247189892
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -94,7 +94,7 @@ public interface RepositorySystemSession {
String getChecksumPolicy();
/**
- * Gets the global update policy. If set, the global update policy
overrides the update policies of the remote
+ * Gets the global data update policy. If set, the global update policy
overrides the update policies of the remote
Review Comment:
IMHO, "data", as we call consequently the other "metadata" everywhere. Yes,
in resolver, "data" is "artifact", but the point is, it does not have to be
only that. Hence I went with generic "data" and "metadata".
--
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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738783#comment-17738783
]
Tamas Cservenak commented on MRESOLVER-376:
---
As I see, BF does not count with RelocatedArtifact implementation, and it
confuses it. Class {{org.apache.maven.repository.internal.RelocatedArtifact}}
is used by {{org.eclipse.aether.impl.ArtifactDescriptorReader}} (implementation
is in maven-resolver-provider).
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-377) Introduce metadata update policy
[
https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738775#comment-17738775
]
ASF GitHub Bot commented on MRESOLVER-377:
--
michael-o commented on code in PR #308:
URL: https://github.com/apache/maven-resolver/pull/308#discussion_r1247157610
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -94,7 +94,7 @@ public interface RepositorySystemSession {
String getChecksumPolicy();
/**
- * Gets the global update policy. If set, the global update policy
overrides the update policies of the remote
+ * Gets the global data update policy. If set, the global update policy
overrides the update policies of the remote
Review Comment:
data or artifact?
> Introduce metadata update policy
>
>
> Key: MRESOLVER-377
> URL: https://issues.apache.org/jira/browse/MRESOLVER-377
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.14
>
>
> Basically double the update policy, from RemoteRepository all way where
> needed, and make Resolver support separate "data" updatePolicy and "metadata"
> updatePolicy.
> Maven does not have to make use of this (setting updatePolicy ==
> metadataUpdatePolicy results in functionality like today, where there is only
> one policy).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #308: [MRESOLVER-377] Introduce metadataUpdatePolicy
michael-o commented on code in PR #308:
URL: https://github.com/apache/maven-resolver/pull/308#discussion_r1247157610
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -94,7 +94,7 @@ public interface RepositorySystemSession {
String getChecksumPolicy();
/**
- * Gets the global update policy. If set, the global update policy
overrides the update policies of the remote
+ * Gets the global data update policy. If set, the global update policy
overrides the update policies of the remote
Review Comment:
data or artifact?
--
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-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738770#comment-17738770 ] ASF GitHub Bot commented on MNG-7532: - slachiewicz commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613763443 Then we can also think how to support slf4j 1 and 2. More and more libs switch to v2 > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7825) XML entity in pom cause NPE in MXSerializer during install
[
https://issues.apache.org/jira/browse/MNG-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738768#comment-17738768
]
Guillaume Nodet commented on MNG-7825:
--
It seems to be fixed now in master with the switch to stax parser.
> XML entity in pom cause NPE in MXSerializer during install
> --
>
> Key: MNG-7825
> URL: https://issues.apache.org/jira/browse/MNG-7825
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
>
> When we have a xml entity in project, like:
> {code}
> test < test
> {code}
> we will have:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke "String.length()"
> because "str" is null
> at java.io.Writer.write (Writer.java:278)
> at org.codehaus.plexus.util.xml.pull.MXSerializer.entityRef
> (MXSerializer.java:806)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:81)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:40)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer.transform
> (ConsumerPomArtifactTransformer.java:195)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer$ConsumerPomArtifact.lambda$transformer$1
> (ConsumerPomArtifactTransformer.java:175)
> at org.apache.maven.internal.transformation.OnChangeTransformer.mayUpdate
> (OnChangeTransformer.java:93)
> at org.apache.maven.internal.transformation.OnChangeTransformer.get
> (OnChangeTransformer.java:72)
> at org.apache.maven.internal.transformation.TransformedArtifact.getFile
> (TransformedArtifact.java:76)
> at org.apache.maven.RepositoryUtils.toArtifact (RepositoryUtils.java:159)
> at org.apache.maven.plugins.install.InstallMojo.processProject
> (InstallMojo.java:227)
> at org.apache.maven.plugins.install.InstallMojo.execute
> (InstallMojo.java:144)
> {noformat}
> works in 3.9.3, 4.0.0-alpha-5
> m-install-p - 3.1.1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738760#comment-17738760
]
Snjezana Peco edited comment on MRESOLVER-376 at 6/29/23 8:16 PM:
--
> Seems this is a bug in BF collector, above is a workaround.
+1
was (Author: JIRAUSER301133):
> Seems this is a bug in BF collector, above is a workaround.
+1
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738761#comment-17738761
]
Tamas Cservenak commented on MRESOLVER-376:
---
Even more interesting: the system-rules POM uses version range (on.a defunct
dependency):
https://repo.maven.apache.org/maven2/com/github/stefanbirkner/system-rules/1.19.0/system-rules-1.19.0.pom
And it chooses 4.11 that is newest junit:junit-dep, that in turn relocates to
junit:junit:4.11, but for some reason here BF chokes.
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738760#comment-17738760
]
Snjezana Peco commented on MRESOLVER-376:
-
> Seems this is a bug in BF collector, above is a workaround.
+1
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738758#comment-17738758
]
Tamas Cservenak commented on MRESOLVER-376:
---
The interesting bit:
{noformat}
[INFO] +- com.github.stefanbirkner:system-rules:jar:1.19.0:test
[INFO] | +- (junit:junit-dep:jar:4.10:test - omitted for conflict with 4.13.1)
[INFO] | \- (junit:junit:jar:4.11-beta-1:test - omitted for conflict with
4.13.1)
{noformat}
As positive, BF chokes on {{junit:junit:jar:4.11}}
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738753#comment-17738753
]
Tamas Cservenak commented on MRESOLVER-376:
---
Just FTR the "reproducer" is this GH commit (if the repo maybe fixes the issue,
to not loose it)
https://github.com/snowflakedb/snowflake-kafka-connector/tree/52f0a8a821f748b0715f49462a67b4b5cf1800fe
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738752#comment-17738752
]
Tamas Cservenak edited comment on MRESOLVER-376 at 6/29/23 7:32 PM:
Got it: the system rules uses ancient Junit, this one:
https://repo.maven.apache.org/maven2/junit/junit-dep/4.11-beta-1/junit-dep-4.11-beta-1.pom
-And it _relocates onto itself_ => endless loop-
Wrong, it relocates from junit-dep to junit... looking more
was (Author: cstamas):
Got it: the system rules uses ancient Junit, this one:
https://repo.maven.apache.org/maven2/junit/junit-dep/4.11-beta-1/junit-dep-4.11-beta-1.pom
And it _relocates onto itself_ => endless loop
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738752#comment-17738752
]
Tamas Cservenak commented on MRESOLVER-376:
---
Got it: the system rules uses ancient Junit, this one:
https://repo.maven.apache.org/maven2/junit/junit-dep/4.11-beta-1/junit-dep-4.11-beta-1.pom
And it _relocates onto itself_ => endless loop
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7828) Bump guava from 31.1-jre to 32.0.1-jre
[ https://issues.apache.org/jira/browse/MNG-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738751#comment-17738751 ] ASF GitHub Bot commented on MNG-7828: - ywluogg commented on PR #1191: URL: https://github.com/apache/maven/pull/1191#issuecomment-1613684600 I'm curious are there plans to bump this in 3.8.X? > Bump guava from 31.1-jre to 32.0.1-jre > -- > > Key: MNG-7828 > URL: https://issues.apache.org/jira/browse/MNG-7828 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.x-candidate, 4.0.x-candidate >Reporter: Bruno Candido Volpato da Cunha >Priority: Major > > Currently used version is in the range of CVE-2023-2976, which was fixed in > 32.0.0. > > Please check [https://osv.dev/vulnerability/GHSA-7g45-4rm6-3mm3] for more > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738750#comment-17738750
]
Tamas Cservenak commented on MRESOLVER-376:
---
```diff
diff --git a/pom.xml b/pom.xml
index f2fa58e..e14d153 100644
--- a/pom.xml
+++ b/pom.xml
@@ -481,6 +481,12 @@
system-rules
1.19.0
test
+
+
+junit
+junit
+
+
```
Seems this is a bug in BF collector, above is a workaround.
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-376:
--
Fix Version/s: 1.9.14
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738750#comment-17738750
]
Tamas Cservenak edited comment on MRESOLVER-376 at 6/29/23 7:27 PM:
{noformat}
diff --git a/pom.xml b/pom.xml
index f2fa58e..e14d153 100644
--- a/pom.xml
+++ b/pom.xml
@@ -481,6 +481,12 @@
system-rules
1.19.0
test
+
+
+junit
+junit
+
+
{noformat}
Seems this is a bug in BF collector, above is a workaround.
was (Author: cstamas):
```diff
diff --git a/pom.xml b/pom.xml
index f2fa58e..e14d153 100644
--- a/pom.xml
+++ b/pom.xml
@@ -481,6 +481,12 @@
system-rules
1.19.0
test
+
+
+junit
+junit
+
+
```
Seems this is a bug in BF collector, above is a workaround.
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738747#comment-17738747
]
Snjezana Peco commented on MRESOLVER-376:
-
I have tested on both: maven 3.9.1 and 3.9.3
Please see
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738742#comment-17738742
]
Tamas Cservenak commented on MRESOLVER-376:
---
Maven 3.9.0 uses Resolver 1.9.4
Maven 3.9.1 uses Resolver 1.9.7
Maven 3.9.2 uses Resolver 1.9.10
Maven 3.9.3 uses Resolver 1.9.13
How come this issue mark "affected" 1.9.13 but shows Maven 3.9.1, please clarify
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738741#comment-17738741
]
Tamas Cservenak commented on MRESOLVER-376:
---
[~wecai]ping
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-377: -- Fix Version/s: 1.9.14 > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738731#comment-17738731 ] ASF GitHub Bot commented on MNG-7532: - gnodet commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613621466 > > We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. > > Sure and we comply to that, only thing is that end user can only expect maven logging framework to be integrated with maven ecosystem (think CI and maven customizations) so if the plugin provider wants something well integrated it has to use that. frontend maven plugin forwarded node logs to maven logging system for that to give an example. > > > It should not be important what logging framework is used in Maven core. > > Probably a good wish but factually it is. > > > Technically we can forward logging message from one framework to another and it can be transparent for plugins code. > > Good wish too but there are several cases which are not trivial. Personally I see it as limitations when deployed inside maven and most plugins have work arounds for that so all good, but we are not neutral enough (as the JVM is) to support anything. It is more or less the same than we are not 100% isolated between plugins - classloader is partially only, env is almost not isolated etc... > > Not sure about the spring reference but it is the same, they work in some env but not always and this is ok. > > The only thing maven guarantees is that the plugin API will go through maven logging system so if integration is customized it will get the logs, anything else is not guaranteed - except JUL by construction indeed. If we: * provide a simple abstraction for mojo (the current Log) * export major APIs (commons-logging and slf4j * redirect those, in addition to JUL This should cover most basic cases. If course, libraries that do setup specifically a logging framework, it will most certainly not be integrated, but we can't do much about that. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
gnodet commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613621466 > > We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. > > Sure and we comply to that, only thing is that end user can only expect maven logging framework to be integrated with maven ecosystem (think CI and maven customizations) so if the plugin provider wants something well integrated it has to use that. frontend maven plugin forwarded node logs to maven logging system for that to give an example. > > > It should not be important what logging framework is used in Maven core. > > Probably a good wish but factually it is. > > > Technically we can forward logging message from one framework to another and it can be transparent for plugins code. > > Good wish too but there are several cases which are not trivial. Personally I see it as limitations when deployed inside maven and most plugins have work arounds for that so all good, but we are not neutral enough (as the JVM is) to support anything. It is more or less the same than we are not 100% isolated between plugins - classloader is partially only, env is almost not isolated etc... > > Not sure about the spring reference but it is the same, they work in some env but not always and this is ok. > > The only thing maven guarantees is that the plugin API will go through maven logging system so if integration is customized it will get the logs, anything else is not guaranteed - except JUL by construction indeed. If we: * provide a simple abstraction for mojo (the current Log) * export major APIs (commons-logging and slf4j * redirect those, in addition to JUL This should cover most basic cases. If course, libraries that do setup specifically a logging framework, it will most certainly not be integrated, but we can't do much about that. -- 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-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738727#comment-17738727 ] ASF GitHub Bot commented on MRESOLVER-377: -- cstamas opened a new pull request, #308: URL: https://github.com/apache/maven-resolver/pull/308 Split the policies applied in case of data and metadata application. --- https://issues.apache.org/jira/browse/MRESOLVER-377 > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #308: [MRESOLVER-377] Introduce metadataUpdatePolicy
cstamas opened a new pull request, #308: URL: https://github.com/apache/maven-resolver/pull/308 Split the policies applied in case of data and metadata application. --- https://issues.apache.org/jira/browse/MRESOLVER-377 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-377) Introduce metadata update policy
Tamas Cservenak created MRESOLVER-377: - Summary: Introduce metadata update policy Key: MRESOLVER-377 URL: https://issues.apache.org/jira/browse/MRESOLVER-377 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Basically double the update policy, from RemoteRepository all way where needed, and make Resolver support separate "data" updatePolicy and "metadata" updatePolicy. Maven does not have to make use of this (setting updatePolicy == metadataUpdatePolicy results in functionality like today, where there is only one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738726#comment-17738726 ] ASF GitHub Bot commented on MNG-7532: - rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613609202 > We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. Sure and we comply to that, only thing is that end user can only expect maven logging framework to be integrated with maven ecosystem (think CI and maven customizations) so if the plugin provider wants something well integrated it has to use that. frontend maven plugin forwarded node logs to maven logging system for that to give an example. > It should not be important what logging framework is used in Maven core. Probably a good wish but factually it is. > Technically we can forward logging message from one framework to another and it can be transparent for plugins code. Good wish too but there are several cases which are not trivial. Personally I see it as limitations when deployed inside maven and most plugins have work arounds for that so all good, but we are not neutral enough (as the JVM is) to support anything. It is more or less the same than we are not 100% isolated between plugins - classloader is partially only, env is almost not isolated etc... Not sure about the spring reference but it is the same, they work in some env but not always and this is ok. The only thing maven guarantees is that the plugin API will go through maven logging system so if integration is customized it will get the logs, anything else is not guaranteed - except JUL by construction indeed. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613609202 > We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. Sure and we comply to that, only thing is that end user can only expect maven logging framework to be integrated with maven ecosystem (think CI and maven customizations) so if the plugin provider wants something well integrated it has to use that. frontend maven plugin forwarded node logs to maven logging system for that to give an example. > It should not be important what logging framework is used in Maven core. Probably a good wish but factually it is. > Technically we can forward logging message from one framework to another and it can be transparent for plugins code. Good wish too but there are several cases which are not trivial. Personally I see it as limitations when deployed inside maven and most plugins have work arounds for that so all good, but we are not neutral enough (as the JVM is) to support anything. It is more or less the same than we are not 100% isolated between plugins - classloader is partially only, env is almost not isolated etc... Not sure about the spring reference but it is the same, they work in some env but not always and this is ok. The only thing maven guarantees is that the plugin API will go through maven logging system so if integration is customized it will get the logs, anything else is not guaranteed - except JUL by construction indeed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738719#comment-17738719 ] ASF GitHub Bot commented on MNG-7532: - slawekjaranowski commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613588496 For Maven plugins we can provide own API or abstraction ... but users can use third party library for implementing plugin code. We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. It should not be important what logging framework is used in Maven core. Technically we can forward logging message from one framework to another and it can be transparent for plugins code. So I'm for not providing next abstraction but allow users use some of commonly available frameworks, like spring-boot does: https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
slawekjaranowski commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613588496 For Maven plugins we can provide own API or abstraction ... but users can use third party library for implementing plugin code. We can not expect that all code in plugins only use Maven and JDK API, thirt party library used in plugins code can uses any logging framework. It should not be important what logging framework is used in Maven core. Technically we can forward logging message from one framework to another and it can be transparent for plugins code. So I'm for not providing next abstraction but allow users use some of commonly available frameworks, like spring-boot does: https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging -- 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-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738627#comment-17738627 ] ASF GitHub Bot commented on MNG-7532: - rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613449431 yes, slf4j was never validated for mojo, there was an excess of enthusiasm in the javadoc but it was never validated nor ack-ed by the community so no big deal. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
rmannibucau commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613449431 yes, slf4j was never validated for mojo, there was an excess of enthusiasm in the javadoc but it was never validated nor ack-ed by the community so no big deal. -- 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-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738625#comment-17738625 ] ASF GitHub Bot commented on MNG-7532: - gnodet commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1613438697 > it's incomplete - we would also update maven site and say that slf4j introduced for logging in 3.1 is now obsolete? It seems to me that https://maven.apache.org/maven-logging.html is mostly about the logging system in general, not really the api to use for mojos. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #1179: Remove references to deprecated ReaderFactory in non generated code
gnodet closed pull request #1179: Remove references to deprecated ReaderFactory in non generated code URL: https://github.com/apache/maven/pull/1179 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
Snjezana Peco created MRESOLVER-376:
---
Summary: StackOverflowError at
BfDependencyCollector.processDependency
Key: MRESOLVER-376
URL: https://issues.apache.org/jira/browse/MRESOLVER-376
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Affects Versions: 1.9.13
Reporter: Snjezana Peco
Steps to reproduce:
{code:java}
$ mvn -v
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
$ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
$ cd snowflake-kafka-connector
$ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
A related issue - [https://github.com/redhat-developer/vscode-java/issues/3085]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-310) Add resource bundle property "Edit" to site-renderer.properties
Michael Osipov created DOXIASITETOOLS-310: - Summary: Add resource bundle property "Edit" to site-renderer.properties Key: DOXIASITETOOLS-310 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-310 Project: Maven Doxia Sitetools Issue Type: Task Components: Site renderer Affects Versions: 2.0.0-M10 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0-M11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSKINS-233) site-macros.vm contains untranslated "Edit" label
Michael Osipov created MSKINS-233:
-
Summary: site-macros.vm contains untranslated "Edit" label
Key: MSKINS-233
URL: https://issues.apache.org/jira/browse/MSKINS-233
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-2.0.0-M6
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: fluido-2.0.0-M7
Content: {{}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-375) Several key aspects are broken in provided and trusted checksum feature
[ https://issues.apache.org/jira/browse/MRESOLVER-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-375: -- Description: Several key aspects are broken in provided and trusted checksum feature of resolver: * trusted checksum post processor: the checksum algorithm is not prefixed (as documented) * the trusted to provided adapter is defunct without MRM being configured * the existing ProvidedChecksumsSource interface is broken, needs to be replaced * some unused loggers and misplaced logging (ie. log may be misleading, move it to actual file reading) was: Several key aspects are broken in provided and trusted checksum feature of resolver: * trusted checksum post processor: the checksum algorithm is not prefixed (as documented) * the trusted to provided adapter is defunct without MRM being configured * the existing ProvidedChecksumsSource interface is broken, needs to be replaced > Several key aspects are broken in provided and trusted checksum feature > --- > > Key: MRESOLVER-375 > URL: https://issues.apache.org/jira/browse/MRESOLVER-375 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Several key aspects are broken in provided and trusted checksum feature of > resolver: > * trusted checksum post processor: the checksum algorithm is not prefixed (as > documented) > * the trusted to provided adapter is defunct without MRM being configured > * the existing ProvidedChecksumsSource interface is broken, needs to be > replaced > * some unused loggers and misplaced logging (ie. log may be misleading, move > it to actual file reading) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSKINS-232) Upgrade to Doxia Sitetools 2.0.0-M11
Michael Osipov created MSKINS-232: - Summary: Upgrade to Doxia Sitetools 2.0.0-M11 Key: MSKINS-232 URL: https://issues.apache.org/jira/browse/MSKINS-232 Project: Maven Skins Issue Type: Dependency upgrade Components: Fluido Skin Reporter: Michael Osipov Assignee: Michael Osipov Fix For: fluido-2.0.0-M6 This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSKINS-232) Upgrade to Doxia Sitetools 2.0.0-M11
[ https://issues.apache.org/jira/browse/MSKINS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-232: -- Fix Version/s: fluido-2.0.0-M7 (was: fluido-2.0.0-M6) > Upgrade to Doxia Sitetools 2.0.0-M11 > > > Key: MSKINS-232 > URL: https://issues.apache.org/jira/browse/MSKINS-232 > Project: Maven Skins > Issue Type: Dependency upgrade > Components: Fluido Skin >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-2.0.0-M7 > > > This will also include the upgrade in ITs: > * Maven Site Plugin 4.0.0-M9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSKINS-232) Upgrade to Doxia Sitetools 2.0.0-M11
[ https://issues.apache.org/jira/browse/MSKINS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-232: -- Description: This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M9 was: This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M7 > Upgrade to Doxia Sitetools 2.0.0-M11 > > > Key: MSKINS-232 > URL: https://issues.apache.org/jira/browse/MSKINS-232 > Project: Maven Skins > Issue Type: Dependency upgrade > Components: Fluido Skin >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-2.0.0-M6 > > > This will also include the upgrade in ITs: > * Maven Site Plugin 4.0.0-M9 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-309) Add resource bundle property "External Links" to site-renderer.properties
Michael Osipov created DOXIASITETOOLS-309: - Summary: Add resource bundle property "External Links" to site-renderer.properties Key: DOXIASITETOOLS-309 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-309 Project: Maven Doxia Sitetools Issue Type: Task Components: Site renderer Affects Versions: 2.0.0-M10 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0-M11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSKINS-231) site.vm contains untranslated "External Links" label
Michael Osipov created MSKINS-231:
-
Summary: site.vm contains untranslated "External Links" label
Key: MSKINS-231
URL: https://issues.apache.org/jira/browse/MSKINS-231
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-2.0.0-M6
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: fluido-2.0.0-M7
Content: {{External Links }}. The label needs to be moved to Doxia Site Renderer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-375) Several key aspects are broken in provided and trusted checksum feature
[ https://issues.apache.org/jira/browse/MRESOLVER-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738579#comment-17738579 ] ASF GitHub Bot commented on MRESOLVER-375: -- cstamas opened a new pull request, #307: URL: https://github.com/apache/maven-resolver/pull/307 Several key aspects are broken in provided and trusted checksum feature of resolver: * trusted checksum post processor: the checksum algorithm is not prefixed (as documented) * the trusted to provided adapter is defunct without MRM being configured * the existing ProvidedChecksumsSource interface is broken, needs to be replaced --- https://issues.apache.org/jira/browse/MRESOLVER-375 > Several key aspects are broken in provided and trusted checksum feature > --- > > Key: MRESOLVER-375 > URL: https://issues.apache.org/jira/browse/MRESOLVER-375 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Several key aspects are broken in provided and trusted checksum feature of > resolver: > * trusted checksum post processor: the checksum algorithm is not prefixed (as > documented) > * the trusted to provided adapter is defunct without MRM being configured > * the existing ProvidedChecksumsSource interface is broken, needs to be > replaced -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSKINS-230) Text in / ignore default alignment
[
https://issues.apache.org/jira/browse/MSKINS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSKINS-230.
-
Resolution: Fixed
Fixed with
[85123d7be9f42c98712ff94e18619095ab284a9f|[https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=85123d7be9f42c98712ff94e18619095ab284a9f].]
> Text in / ignore default alignment
> --
>
> Key: MSKINS-230
> URL: https://issues.apache.org/jira/browse/MSKINS-230
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-2.0.0-M7
>
>
> Table (header) cells lose default alignment because Bootstrap by default
> enforces:
> {noformat}
> .table th,
> .table td {
> padding: 8px;
> line-height: 20px;
> text-align: left;
> vertical-align: top;
> border-top: 1px solid #dd;
> } {noformat}
> We need to revert it and not enfore any alignment otherwise {{}} elements
> aren't centered anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSKINS-230) Text in / ignore default alignment
[
https://issues.apache.org/jira/browse/MSKINS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738575#comment-17738575
]
Michael Osipov edited comment on MSKINS-230 at 6/29/23 1:22 PM:
Fixed with
[85123d7be9f42c98712ff94e18619095ab284a9f|https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=85123d7be9f42c98712ff94e18619095ab284a9f].
was (Author: michael-o):
Fixed with
[85123d7be9f42c98712ff94e18619095ab284a9f|[https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=85123d7be9f42c98712ff94e18619095ab284a9f].]
> Text in / ignore default alignment
> --
>
> Key: MSKINS-230
> URL: https://issues.apache.org/jira/browse/MSKINS-230
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-2.0.0-M7
>
>
> Table (header) cells lose default alignment because Bootstrap by default
> enforces:
> {noformat}
> .table th,
> .table td {
> padding: 8px;
> line-height: 20px;
> text-align: left;
> vertical-align: top;
> border-top: 1px solid #dd;
> } {noformat}
> We need to revert it and not enfore any alignment otherwise {{}} elements
> aren't centered anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSKINS-230) Label in / ignore default alignment
Michael Osipov created MSKINS-230:
-
Summary: Label in / ignore default alignment
Key: MSKINS-230
URL: https://issues.apache.org/jira/browse/MSKINS-230
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-2.0.0-M6
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: fluido-2.0.0-M7
Table (header) cells lose default alignment because Bootstrap by default
enforces:
{noformat}
.table th,
.table td {
padding: 8px;
line-height: 20px;
text-align: left;
vertical-align: top;
border-top: 1px solid #dd;
} {noformat}
We need to revert it and not enfore any alignment otherwise {{}} elements
aren't centered anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSKINS-230) Text in / ignore default alignment
[
https://issues.apache.org/jira/browse/MSKINS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-230:
--
Summary: Text in / ignore default alignment (was: Label in
/ ignore default alignment)
> Text in / ignore default alignment
> --
>
> Key: MSKINS-230
> URL: https://issues.apache.org/jira/browse/MSKINS-230
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-2.0.0-M7
>
>
> Table (header) cells lose default alignment because Bootstrap by default
> enforces:
> {noformat}
> .table th,
> .table td {
> padding: 8px;
> line-height: 20px;
> text-align: left;
> vertical-align: top;
> border-top: 1px solid #dd;
> } {noformat}
> We need to revert it and not enfore any alignment otherwise {{}} elements
> aren't centered anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-375) Several key aspects are broken in provided and trusted checksum feature
Tamas Cservenak created MRESOLVER-375: - Summary: Several key aspects are broken in provided and trusted checksum feature Key: MRESOLVER-375 URL: https://issues.apache.org/jira/browse/MRESOLVER-375 Project: Maven Resolver Issue Type: Bug Components: Resolver Affects Versions: 1.9.13 Reporter: Tamas Cservenak Fix For: 1.9.14 Several key aspects are broken in provided and trusted checksum feature of resolver: * trusted checksum post processor: the checksum algorithm is not prefixed (as documented) * the trusted to provided adapter is defunct without MRM being configured * the existing ProvidedChecksumsSource interface is broken, needs to be replaced -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request, #94: Bump groovy from 3.0.17 to 3.0.18
dependabot[bot] opened a new pull request, #94: URL: https://github.com/apache/maven-artifact-transfer/pull/94 Bumps [groovy](https://github.com/apache/groovy) from 3.0.17 to 3.0.18. Commits See full diff in https://github.com/apache/groovy/commits";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot 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
[jira] [Commented] (MNG-7829) CLI properties passed with -D are not accessible with session.getSystemProperties()
[
https://issues.apache.org/jira/browse/MNG-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738525#comment-17738525
]
Guillaume Nodet commented on MNG-7829:
--
Ok, I misunderstood, I thought those were not available from
{{System.getProperty()}} anymore. Those are not available in _maven session
system properties_ .
The code to set the java system property is still available at
https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cR1570
> CLI properties passed with -D are not accessible with
> session.getSystemProperties()
> ---
>
> Key: MNG-7829
> URL: https://issues.apache.org/jira/browse/MNG-7829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-7
>Reporter: Jerome Prinet
>Assignee: Guillaume Nodet
>Priority: Minor
>
> h3. Context
> * Maven _4.0.0-alpha-6_ and above
> * A Maven extension collecting CLI arguments passed with _-D_
> h3. Issue
> In a Maven extension, I am collecting CLI arguments which allow to skip tests
> if present ({_}skipTests, skipITs, maven.test.skip{_}).
> The problem is that since Maven {_}4.0.0-alpha06{_}, these informations are
> not part of the
> [session.systemProperties|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getSystemProperties()]
> anymore.
> This is working fine until [this
> commit|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified]
> if not mistaken.
> The missing instruction being [this
> one|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cL1546].
> *If I add this back on the latest version of master, I am able to collect the
> information.*
> h3. Alternative
> Those properties can be accessed via the
> [session.getUserProperties()|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getUserProperties()]
> Please confirm if this is the expected way to collect the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7829) CLI properties passed with -D are not accessible with session.getSystemProperties()
[
https://issues.apache.org/jira/browse/MNG-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7829.
Resolution: Not A Problem
> CLI properties passed with -D are not accessible with
> session.getSystemProperties()
> ---
>
> Key: MNG-7829
> URL: https://issues.apache.org/jira/browse/MNG-7829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-7
>Reporter: Jerome Prinet
>Assignee: Guillaume Nodet
>Priority: Minor
>
> h3. Context
> * Maven _4.0.0-alpha-6_ and above
> * A Maven extension collecting CLI arguments passed with _-D_
> h3. Issue
> In a Maven extension, I am collecting CLI arguments which allow to skip tests
> if present ({_}skipTests, skipITs, maven.test.skip{_}).
> The problem is that since Maven {_}4.0.0-alpha06{_}, these informations are
> not part of the
> [session.systemProperties|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getSystemProperties()]
> anymore.
> This is working fine until [this
> commit|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified]
> if not mistaken.
> The missing instruction being [this
> one|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cL1546].
> *If I add this back on the latest version of master, I am able to collect the
> information.*
> h3. Alternative
> Those properties can be accessed via the
> [session.getUserProperties()|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getUserProperties()]
> Please confirm if this is the expected way to collect the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-shared-utils] elharo closed pull request #164: test a hypothesis; don't commit
elharo closed pull request #164: test a hypothesis; don't commit URL: https://github.com/apache/maven-shared-utils/pull/164 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7830) Switch from plexus-xml to stax / woodstox
[ https://issues.apache.org/jira/browse/MNG-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7830. Resolution: Fixed > Switch from plexus-xml to stax / woodstox > - > > Key: MNG-7830 > URL: https://issues.apache.org/jira/browse/MNG-7830 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7830) Switch from plexus-xml to stax / woodstox
[ https://issues.apache.org/jira/browse/MNG-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7830: - Issue Type: New Feature (was: Dependency upgrade) > Switch from plexus-xml to stax / woodstox > - > > Key: MNG-7830 > URL: https://issues.apache.org/jira/browse/MNG-7830 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7830) Switch from plexus-xml to stax / woodstox
[ https://issues.apache.org/jira/browse/MNG-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738468#comment-17738468 ] ASF GitHub Bot commented on MNG-7830: - gnodet merged PR #1185: URL: https://github.com/apache/maven/pull/1185 > Switch from plexus-xml to stax / woodstox > - > > Key: MNG-7830 > URL: https://issues.apache.org/jira/browse/MNG-7830 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #1185: [MNG-7830] Switch from plexus-xml to stax / woodstox
gnodet merged PR #1185: URL: https://github.com/apache/maven/pull/1185 -- 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-integration-testing] gnodet merged pull request #274: [MNG-7830] Switch from plexus-xml to stax / woodstox
gnodet merged PR #274: URL: https://github.com/apache/maven-integration-testing/pull/274 -- 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-7829) CLI properties passed with -D are not accessible with session.getSystemProperties()
[
https://issues.apache.org/jira/browse/MNG-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738453#comment-17738453
]
Michael Osipov commented on MNG-7829:
-
[~gnodet] , the user is passing Maven user properties, not system properties.
So his code has wrong from begin with. I don't see a problem here.
> CLI properties passed with -D are not accessible with
> session.getSystemProperties()
> ---
>
> Key: MNG-7829
> URL: https://issues.apache.org/jira/browse/MNG-7829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-7
>Reporter: Jerome Prinet
>Assignee: Guillaume Nodet
>Priority: Minor
>
> h3. Context
> * Maven _4.0.0-alpha-6_ and above
> * A Maven extension collecting CLI arguments passed with _-D_
> h3. Issue
> In a Maven extension, I am collecting CLI arguments which allow to skip tests
> if present ({_}skipTests, skipITs, maven.test.skip{_}).
> The problem is that since Maven {_}4.0.0-alpha06{_}, these informations are
> not part of the
> [session.systemProperties|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getSystemProperties()]
> anymore.
> This is working fine until [this
> commit|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified]
> if not mistaken.
> The missing instruction being [this
> one|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cL1546].
> *If I add this back on the latest version of master, I am able to collect the
> information.*
> h3. Alternative
> Those properties can be accessed via the
> [session.getUserProperties()|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getUserProperties()]
> Please confirm if this is the expected way to collect the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738446#comment-17738446
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
cstamas commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1246349148
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +285,26 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Additional Maven dependencies to be used in the test execution
classpath.
Review Comment:
LGTM
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] cstamas commented on a diff in pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test runtime classpath
cstamas commented on code in PR #667: URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1246349148 ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -281,6 +285,26 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "maven.test.additionalClasspath") private String[] additionalClasspathElements; +/** + * Additional Maven dependencies to be used in the test execution classpath. Review Comment: LGTM -- 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-7829) CLI properties passed with -D are not accessible with session.getSystemProperties()
[
https://issues.apache.org/jira/browse/MNG-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738443#comment-17738443
]
Guillaume Nodet commented on MNG-7829:
--
System properties have always been used as a way to share static global
variables or to configure libraries globally. I don't think that can be
avoided unfortunately.
> CLI properties passed with -D are not accessible with
> session.getSystemProperties()
> ---
>
> Key: MNG-7829
> URL: https://issues.apache.org/jira/browse/MNG-7829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-7
>Reporter: Jerome Prinet
>Assignee: Guillaume Nodet
>Priority: Minor
>
> h3. Context
> * Maven _4.0.0-alpha-6_ and above
> * A Maven extension collecting CLI arguments passed with _-D_
> h3. Issue
> In a Maven extension, I am collecting CLI arguments which allow to skip tests
> if present ({_}skipTests, skipITs, maven.test.skip{_}).
> The problem is that since Maven {_}4.0.0-alpha06{_}, these informations are
> not part of the
> [session.systemProperties|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getSystemProperties()]
> anymore.
> This is working fine until [this
> commit|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified]
> if not mistaken.
> The missing instruction being [this
> one|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cL1546].
> *If I add this back on the latest version of master, I am able to collect the
> information.*
> h3. Alternative
> Those properties can be accessed via the
> [session.getUserProperties()|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getUserProperties()]
> Please confirm if this is the expected way to collect the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MNG-7829) CLI properties passed with -D are not accessible with session.getSystemProperties()
[
https://issues.apache.org/jira/browse/MNG-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reopened MNG-7829:
--
Assignee: Guillaume Nodet
> CLI properties passed with -D are not accessible with
> session.getSystemProperties()
> ---
>
> Key: MNG-7829
> URL: https://issues.apache.org/jira/browse/MNG-7829
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-7
>Reporter: Jerome Prinet
>Assignee: Guillaume Nodet
>Priority: Minor
>
> h3. Context
> * Maven _4.0.0-alpha-6_ and above
> * A Maven extension collecting CLI arguments passed with _-D_
> h3. Issue
> In a Maven extension, I am collecting CLI arguments which allow to skip tests
> if present ({_}skipTests, skipITs, maven.test.skip{_}).
> The problem is that since Maven {_}4.0.0-alpha06{_}, these informations are
> not part of the
> [session.systemProperties|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getSystemProperties()]
> anymore.
> This is working fine until [this
> commit|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified]
> if not mistaken.
> The missing instruction being [this
> one|https://github.com/apache/maven/commit/a1fa3eb5346f562a745f054650eee1e84c44db30?diff=unified#diff-b8b814f5b6b3855ae79dc45a0266b94871193dcef42803c316e07409e94af35cL1546].
> *If I add this back on the latest version of master, I am able to collect the
> information.*
> h3. Alternative
> Those properties can be accessed via the
> [session.getUserProperties()|https://maven.apache.org/ref/3.9.3/maven-core/apidocs/org/apache/maven/execution/MavenSession.html#getUserProperties()]
> Please confirm if this is the expected way to collect the data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738441#comment-17738441
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1246327954
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +285,26 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Additional Maven dependencies to be used in the test execution
classpath.
Review Comment:
```suggestion
* Additional Maven dependencies to be added to the test classpath at
runtime
```
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin commented on a diff in pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test runtime classpath
kwin commented on code in PR #667: URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1246327954 ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -281,6 +285,26 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "maven.test.additionalClasspath") private String[] additionalClasspathElements; +/** + * Additional Maven dependencies to be used in the test execution classpath. Review Comment: ```suggestion * Additional Maven dependencies to be added to the test classpath at runtime ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738428#comment-17738428
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
cstamas commented on PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612603986
In fact, IMHO we should revisit ALL these plugins having "artifact-like"
(GAV) parameters and using resolver to resolve them, and
* mark all these configurations as "usable for out-of-reactor plugins only"
(or it is user who needs to hack in proper build order by whatever means he can)
* come up with some proper solution in Maven to make sorting aware of ALL
these
Biggest problem is that "by chance" the ordering may be good, and seemingly
everything works, but then user changes something completely unrelated (ie.
adds a new module to build), that changes build order, and suddenly this
breaks. In this situations is hard to figure out why breakage happened.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] cstamas commented on pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
cstamas commented on PR #667: URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612603986 In fact, IMHO we should revisit ALL these plugins having "artifact-like" (GAV) parameters and using resolver to resolve them, and * mark all these configurations as "usable for out-of-reactor plugins only" (or it is user who needs to hack in proper build order by whatever means he can) * come up with some proper solution in Maven to make sorting aware of ALL these Biggest problem is that "by chance" the ordering may be good, and seemingly everything works, but then user changes something completely unrelated (ie. adds a new module to build), that changes build order, and suddenly this breaks. In this situations is hard to figure out why breakage happened. -- 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-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738425#comment-17738425
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
cstamas commented on PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612598248
For all non POM/dependency and POM/plugins/plugin/dependency elements,
especially for plugin config like this one (or like compiler anno processor is,
etc) we MUST BE CLEAR that it works ONLY for _external dependencies_. These
elements do NOT participate in project topological sorting, hence, becomes
impossible to use some reactor project for these (without hacks). Moreover, if
using reactor artifacts, this is one of the reasons why users are forced to to
`mvn install` as 1st pass, and from 2nd pass onward "it will work", but again,
what is being used "lags" one build cycle (as installed thing is being used,
not the currently built one).
See for example here https://issues.apache.org/jira/browse/MNG-6877
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] cstamas commented on pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
cstamas commented on PR #667: URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612598248 For all non POM/dependency and POM/plugins/plugin/dependency elements, especially for plugin config like this one (or like compiler anno processor is, etc) we MUST BE CLEAR that it works ONLY for _external dependencies_. These elements do NOT participate in project topological sorting, hence, becomes impossible to use some reactor project for these (without hacks). Moreover, if using reactor artifacts, this is one of the reasons why users are forced to to `mvn install` as 1st pass, and from 2nd pass onward "it will work", but again, what is being used "lags" one build cycle (as installed thing is being used, not the currently built one). See for example here https://issues.apache.org/jira/browse/MNG-6877 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MENFORCER-487) Bump commons-io from 2.11.0 to 2.13.0
[ https://issues.apache.org/jira/browse/MENFORCER-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MENFORCER-487. - Resolution: Fixed > Bump commons-io from 2.11.0 to 2.13.0 > - > > Key: MENFORCER-487 > URL: https://issues.apache.org/jira/browse/MENFORCER-487 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-487) Bump commons-io from 2.11.0 to 2.13.0
[ https://issues.apache.org/jira/browse/MENFORCER-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738386#comment-17738386 ] ASF GitHub Bot commented on MENFORCER-487: -- slawekjaranowski merged PR #277: URL: https://github.com/apache/maven-enforcer/pull/277 > Bump commons-io from 2.11.0 to 2.13.0 > - > > Key: MENFORCER-487 > URL: https://issues.apache.org/jira/browse/MENFORCER-487 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #277: [MENFORCER-487] Bump commons-codec from 1.15 to 1.16.0
slawekjaranowski merged PR #277: URL: https://github.com/apache/maven-enforcer/pull/277 -- 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-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738381#comment-17738381
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612522716
> is it possible to have an IT test? as I cannot see any test here. thanks
Done now, you find it in
https://github.com/apache/maven-surefire/pull/667/files#diff-311598b970ad59d912704889726abb7abbf6d92d3d5382a94d85c8c686ab24b9R21
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin commented on pull request #667: [SUREFIRE-2179] Support adding additional Maven dependencies to the test classpath
kwin commented on PR #667: URL: https://github.com/apache/maven-surefire/pull/667#issuecomment-1612522716 > is it possible to have an IT test? as I cannot see any test here. thanks Done now, you find it in https://github.com/apache/maven-surefire/pull/667/files#diff-311598b970ad59d912704889726abb7abbf6d92d3d5382a94d85c8c686ab24b9R21 -- 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
