[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793167#comment-17793167
]
Dave Moten edited comment on MBUILDCACHE-76 at 12/5/23 7:39 AM:
will it really make a difference to perfomance? Don't need to extract version
just use the pom.xml files in the checksum calculation as well...
was (Author: davidmoten2):
will it really make a difference to perfomance? Don't need to extract version
just use the checksum of the pom.xml files as well...
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793167#comment-17793167
]
Dave Moten commented on MBUILDCACHE-76:
---
will it really make a difference to perfomance? Don't need to extract version
just use the checksum of the pom.xml files as well...
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy edited comment on MBUILDCACHE-76 at 12/5/23 7:33 AM:
--
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
regarding forcing install. This is documented
[here|https://maven.apache.org/extensions/maven-build-cache-extension/how-to.html]
using executionControl/runAlways
was (Author: olamy):
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy edited comment on MBUILDCACHE-76 at 12/5/23 7:25 AM:
--
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
was (Author: olamy):
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy commented on MBUILDCACHE-76:
-
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793159#comment-17793159
]
Dave Moten edited comment on MBUILDCACHE-76 at 12/5/23 7:02 AM:
`nah the problem here is because of the multi module and so projects are part
of the reactor build.`
If I run mvn clean install on a new snapshot version of a single module project
I expect that that version should be present in .m2/repository afterwards.
I move on to project B (completely separate) and try to use that new snapshot
version of project A and it is not found (because build cache maven plugin
skipped it).
Sure this is an edge case because normally when versions change the source code
has changed but I still think the plugin can be robust enough to handle it.
Note that this edge case *is* encountered just after building a release.
Disabling the extension by default is annoying because project users lose
efficiency and educating project users about these edge cases is a pain in the
bum.
I've just confirmed the behaviour with a single module project. Just add the
version to the checksum.
was (Author: davidmoten2):
`nah the problem here is because of the multi module and so projects are part
of the reactor build.`
If I run mvn clean install on a new snapshot version of a single module project
I expect that that version should be present in .m2/repository afterwards.
I move on to project B (completely separate) and try to use that new snapshot
version of project A and it is not found (because build cache maven plugin
skipped it).
Sure this is an edge case because normally when versions change the source code
has changed but I still think the plugin can be robust enough to handle it.
Disabling the extension by default is annoying because project users lose
efficiency and educating project users about these edge cases is a pain in the
bum.
I've just confirmed the behaviour with a single module project. Just add the
version to the checksum.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793159#comment-17793159
]
Dave Moten edited comment on MBUILDCACHE-76 at 12/5/23 7:02 AM:
`nah the problem here is because of the multi module and so projects are part
of the reactor build.`
If I run mvn clean install on a new snapshot version of a single module project
A I expect that that version should be present in .m2/repository afterwards.
I move on to project B (completely separate) and try to use that new snapshot
version of project A and it is not found (because build cache maven plugin
skipped it).
Sure this is an edge case because normally when versions change the source code
has changed but I still think the plugin can be robust enough to handle it.
Note that this edge case *is* encountered just after building a release.
Disabling the extension by default is annoying because project users lose
efficiency and educating project users about these edge cases is a pain in the
bum.
I've just confirmed the behaviour with a single module project. Just add the
version to the checksum.
was (Author: davidmoten2):
`nah the problem here is because of the multi module and so projects are part
of the reactor build.`
If I run mvn clean install on a new snapshot version of a single module project
I expect that that version should be present in .m2/repository afterwards.
I move on to project B (completely separate) and try to use that new snapshot
version of project A and it is not found (because build cache maven plugin
skipped it).
Sure this is an edge case because normally when versions change the source code
has changed but I still think the plugin can be robust enough to handle it.
Note that this edge case *is* encountered just after building a release.
Disabling the extension by default is annoying because project users lose
efficiency and educating project users about these edge cases is a pain in the
bum.
I've just confirmed the behaviour with a single module project. Just add the
version to the checksum.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793159#comment-17793159
]
Dave Moten commented on MBUILDCACHE-76:
---
`nah the problem here is because of the multi module and so projects are part
of the reactor build.`
If I run mvn clean install on a new snapshot version of a single module project
I expect that that version should be present in .m2/repository afterwards.
I move on to project B (completely separate) and try to use that new snapshot
version of project A and it is not found (because build cache maven plugin
skipped it).
Sure this is an edge case because normally when versions change the source code
has changed but I still think the plugin can be robust enough to handle it.
Disabling the extension by default is annoying because project users lose
efficiency and educating project users about these edge cases is a pain in the
bum.
I've just confirmed the behaviour with a single module project. Just add the
version to the checksum.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793148#comment-17793148
]
Olivier Lamy commented on MBUILDCACHE-76:
-
`So this will happen for a single module project as well (multi-module is a
distraction). `
nah the problem here is because of the multi module and so projects are part of
the reactor build.
External dependencies checksum calculation is using version because there is
not access to projects inputs (sources, resources etc..).
But here in the case of a multimodule, the reactor give access to the module
buillds inputs (sources, resources etc..) simply because they are part of the
build.
Inter module dependencies (e.g modules part of the same reactor build) doesn't
care (usually) of version change.
project (version 1.0-SNAPSHOT)
- module A (version 1.0-SNAPSHOT)
- module B (version 1.0-SNAPSHOT) using module A (version 1.0-SNAPSHOT)
When building module B the build cache extension can calculate real checksum of
module A because it has direct access to sources, resources etc...
In this case version number doesn't have any impact because the extension can
calculate if something has really change (version number is not real change of
nothing else has changed :) )
BUT in the case of the build need this version as part of the checksum build
input calculation which is the case of m-plugin-p:descriptor goal which use to
generate plugin metadata, we have a problem :)
if you move all the tests modules using your plugin as invoker tests within the
plugin code itself you may not have issues as those tests will not run when
cache detects no changes.
The other workaround now is to disable the cache for the maven plugin
false
or clean local cache entries: rm -rf ~/.m2/build-cache/v1/
Other than that we need to find a solution for maven-plugin type (when it's
part of reactor build) project but something generic.
A solution I tried was to force m-plugin-p to always run
.
descriptor
but nah doesn't work as mvn clean install means deleted target/classes and so
no way to scan for annotations.
the solution could be a new feature to force restore output of a module.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
[PR] Bump com.diffplug.spotless:spotless-maven-plugin from 2.40.0 to 2.41.1 [maven-parent]
dependabot[bot] opened a new pull request, #152: URL: https://github.com/apache/maven-parent/pull/152 Bumps [com.diffplug.spotless:spotless-maven-plugin](https://github.com/diffplug/spotless) from 2.40.0 to 2.41.1. Changelog Sourced from https://github.com/diffplug/spotless/blob/main/CHANGES.md;>com.diffplug.spotless:spotless-maven-plugin's changelog. spotless-lib and spotless-lib-extra releases If you are a Spotless user (as opposed to developer), then you are probably looking for: https://github.com/diffplug/spotless/blob/main/plugin-gradle/CHANGES.md;>https://github.com/diffplug/spotless/blob/main/plugin-gradle/CHANGES.md https://github.com/diffplug/spotless/blob/main/plugin-maven/CHANGES.md;>https://github.com/diffplug/spotless/blob/main/plugin-maven/CHANGES.md This document is intended for Spotless developers. We adhere to the https://keepachangelog.com/en/1.0.0/;>keepachangelog format (starting after version 1.27.0). [Unreleased] [2.43.1] - 2023-12-04 Fixed Eclipse-based steps which contained any jars with a + in their path were broken, now fixed. (https://redirect.github.com/diffplug/spotless/issues/1860#issuecomment-1826113332;>#1860) Changes Bump default palantir-java-format version to latest 2.28.0 - 2.38.0 on Java 21. (https://redirect.github.com/diffplug/spotless/pull/1920;>#1920) Bump default googleJavaFormat version to latest 1.17.0 - 1.18.1. (https://redirect.github.com/diffplug/spotless/pull/1920;>#1920) Bump default ktfmt version to latest 0.44 - 0.46. (https://redirect.github.com/diffplug/spotless/pull/1927;>#1927) Bump default eclipse version to latest 4.27 - 4.29. (https://redirect.github.com/diffplug/spotless/pull/1939;>#1939) Bump default greclipse version to latest 4.28 - 4.29. (https://redirect.github.com/diffplug/spotless/pull/1939;>#1939) Bump default cdt version to latest 11.1 - 11.3. (https://redirect.github.com/diffplug/spotless/pull/1939;>#1939) [2.43.0] - 2023-11-27 Added Support custom rule sets for Ktlint. (https://redirect.github.com/diffplug/spotless/pull/1896;>#1896) Fixed Fix Eclipse JDT on some settings files. (https://redirect.github.com/diffplug/spotless/pull/1864;>#1864 fixes https://redirect.github.com/diffplug/spotless/issues/1638;>#1638) Changes Bump default ktlint version to latest 1.0.0 - 1.0.1. (https://redirect.github.com/diffplug/spotless/pull/1855;>#1855) Add a Step to remove semicolons from Groovy files. (https://redirect.github.com/diffplug/spotless/pull/1881;>#1881) [2.42.0] - 2023-09-28 Added Support for biome. The Rome project https://biomejs.dev/blog/annoucing-biome/;>was renamed to Biome. The configuration is still the same, but you should switch to the new biome tag / function and adjust the version accordingly. (https://redirect.github.com/diffplug/spotless/issues/1804;>#1804). Support for google-java-format's skip-javadoc-formatting option. (https://redirect.github.com/diffplug/spotless/pull/1793;>#1793) Support configuration of mirrors for P2 repositories in Maven DSL (https://redirect.github.com/diffplug/spotless/issues/1697;>#1697). New line endings mode GIT_ATTRIBUTES_FAST_ALLSAME. (https://redirect.github.com/diffplug/spotless/pull/1838;>#1838) Fixed Fix support for plugins when using Prettier version 3.0.0 and newer. (https://redirect.github.com/diffplug/spotless/pull/1802;>#1802) Fix configuration cache issue around external process started '/usr/bin/git --version'. (https://redirect.github.com/diffplug/spotless/issues/1806;>#1806) Changes Bump default flexmark version to latest 0.64.0 - 0.64.8. (https://redirect.github.com/diffplug/spotless/pull/1801;>#1801) Bump default ktlint version to latest 0.50.0 - 1.0.0. (https://redirect.github.com/diffplug/spotless/pull/1808;>#1808) [2.41.0] - 2023-08-29 Added ... (truncated) Commits https://github.com/diffplug/spotless/commit/6de369e03b36ed96c190dccb122be55e7918553b;>6de369e Published maven/2.41.1 https://github.com/diffplug/spotless/commit/29bb75cdb02677e276f4f2acbb961fbb4f290c07;>29bb75c Published gradle/6.23.3 https://github.com/diffplug/spotless/commit/053c7aeb6a9c363dea6470e14d54058f513bffa3;>053c7ae Published lib/2.43.1 https://github.com/diffplug/spotless/commit/ed88d337f34922f4383b35100f717c7876466680;>ed88d33 Update Equo steps (https://redirect.github.com/diffplug/spotless/issues/1939;>#1939) https://github.com/diffplug/spotless/commit/c4da6c40089abe86bfbbd639acc70ae4795b1958;>c4da6c4 Update changelogs. https://github.com/diffplug/spotless/commit/ee77877d2589bee50a4e8833663e976b5ac68963;>ee77877 Keep eclipseWtp step, remove the long-dormant _ext/eclipse-wtp project (#... https://github.com/diffplug/spotless/commit/7468ace145e0e4350d955156d05de435b86d42f5;>7468ace Update actions/setup-java action to v4
Re: [PR] Bump com.diffplug.spotless:spotless-maven-plugin from 2.40.0 to 2.41.0 [maven-parent]
dependabot[bot] commented on PR #151: URL: https://github.com/apache/maven-parent/pull/151#issuecomment-1839980704 Superseded by #152. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump com.diffplug.spotless:spotless-maven-plugin from 2.40.0 to 2.41.0 [maven-parent]
dependabot[bot] closed pull request #151: Bump com.diffplug.spotless:spotless-maven-plugin from 2.40.0 to 2.41.0 URL: https://github.com/apache/maven-parent/pull/151 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 [maven-surefire]
dependabot[bot] opened a new pull request, #695: URL: https://github.com/apache/maven-surefire/pull/695 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.8.0 to 3.9.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>org.htmlunit:htmlunit's releases. HtmlUnit 3.9.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html;>migration info core-csp: new lib for CSP commons-logging to 1.3.0, commons-io to 2.15.1, commons-lang3 to 3.14.0 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor (CVE-2023-49093). neko: new HTML named entities parser that is up to 20x faster for common entities and some more fixes many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.9.0;>full release notes for details about this release. Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri;>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/a599e36ecc0b19a2ea76b73f7f48365fbb87c28a;>a599e36 version 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/d4c11058e71b6ba5eaaf5d9565c1634b4bbeec1e;>d4c1105 core-js 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/51f0eefd545bca2c17f12f237ba228a08aac4f7f;>51f0eef exclude commons.logging from httpcomponents https://github.com/HtmlUnit/htmlunit/commit/65986a459f15da0eed1616d91efdd65f99120334;>65986a4 code style https://github.com/HtmlUnit/htmlunit/commit/1587961cf4043ea776d38683e53470993bc70771;>1587961 lib updates https://github.com/HtmlUnit/htmlunit/commit/2a972ced6e7cc147a29c86c0e962f2696f9cc4ed;>2a972ce htmx 1.9.9 https://github.com/HtmlUnit/htmlunit/commit/792e8456cd76f7cfd04587d539bd4fa929599000;>792e845 new subproject htmlunit-csp https://github.com/HtmlUnit/htmlunit/commit/e07ba67cc1b030f90a2ad9882f271429345b008d;>e07ba67 fix ms driver check https://github.com/HtmlUnit/htmlunit/commit/e015082aa909fd9e1c2b5f9b26553ddc0ddbbcab;>e015082 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor https://github.com/HtmlUnit/htmlunit/commit/77aeaa85e1fc69e929858ae700b24528275d8d07;>77aeaa8 another minor neko update Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.8.0...3.9.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-surefire/network/alerts). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-failing [maven-surefire]
dependabot[bot] opened a new pull request, #694: URL: https://github.com/apache/maven-surefire/pull/694 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.8.0 to 3.9.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>org.htmlunit:htmlunit's releases. HtmlUnit 3.9.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html;>migration info core-csp: new lib for CSP commons-logging to 1.3.0, commons-io to 2.15.1, commons-lang3 to 3.14.0 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor (CVE-2023-49093). neko: new HTML named entities parser that is up to 20x faster for common entities and some more fixes many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.9.0;>full release notes for details about this release. Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri;>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/a599e36ecc0b19a2ea76b73f7f48365fbb87c28a;>a599e36 version 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/d4c11058e71b6ba5eaaf5d9565c1634b4bbeec1e;>d4c1105 core-js 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/51f0eefd545bca2c17f12f237ba228a08aac4f7f;>51f0eef exclude commons.logging from httpcomponents https://github.com/HtmlUnit/htmlunit/commit/65986a459f15da0eed1616d91efdd65f99120334;>65986a4 code style https://github.com/HtmlUnit/htmlunit/commit/1587961cf4043ea776d38683e53470993bc70771;>1587961 lib updates https://github.com/HtmlUnit/htmlunit/commit/2a972ced6e7cc147a29c86c0e962f2696f9cc4ed;>2a972ce htmx 1.9.9 https://github.com/HtmlUnit/htmlunit/commit/792e8456cd76f7cfd04587d539bd4fa929599000;>792e845 new subproject htmlunit-csp https://github.com/HtmlUnit/htmlunit/commit/e07ba67cc1b030f90a2ad9882f271429345b008d;>e07ba67 fix ms driver check https://github.com/HtmlUnit/htmlunit/commit/e015082aa909fd9e1c2b5f9b26553ddc0ddbbcab;>e015082 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor https://github.com/HtmlUnit/htmlunit/commit/77aeaa85e1fc69e929858ae700b24528275d8d07;>77aeaa8 another minor neko update Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.8.0...3.9.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-surefire/network/alerts). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-passing [maven-surefire]
dependabot[bot] opened a new pull request, #693: URL: https://github.com/apache/maven-surefire/pull/693 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.8.0 to 3.9.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases;>org.htmlunit:htmlunit's releases. HtmlUnit 3.9.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html;>migration info core-csp: new lib for CSP commons-logging to 1.3.0, commons-io to 2.15.1, commons-lang3 to 3.14.0 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor (CVE-2023-49093). neko: new HTML named entities parser that is up to 20x faster for common entities and some more fixes many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.9.0;>full release notes for details about this release. Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri;>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/a599e36ecc0b19a2ea76b73f7f48365fbb87c28a;>a599e36 version 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/d4c11058e71b6ba5eaaf5d9565c1634b4bbeec1e;>d4c1105 core-js 3.9.0 https://github.com/HtmlUnit/htmlunit/commit/51f0eefd545bca2c17f12f237ba228a08aac4f7f;>51f0eef exclude commons.logging from httpcomponents https://github.com/HtmlUnit/htmlunit/commit/65986a459f15da0eed1616d91efdd65f99120334;>65986a4 code style https://github.com/HtmlUnit/htmlunit/commit/1587961cf4043ea776d38683e53470993bc70771;>1587961 lib updates https://github.com/HtmlUnit/htmlunit/commit/2a972ced6e7cc147a29c86c0e962f2696f9cc4ed;>2a972ce htmx 1.9.9 https://github.com/HtmlUnit/htmlunit/commit/792e8456cd76f7cfd04587d539bd4fa929599000;>792e845 new subproject htmlunit-csp https://github.com/HtmlUnit/htmlunit/commit/e07ba67cc1b030f90a2ad9882f271429345b008d;>e07ba67 fix ms driver check https://github.com/HtmlUnit/htmlunit/commit/e015082aa909fd9e1c2b5f9b26553ddc0ddbbcab;>e015082 enable FEATURE_SECURE_PROCESSING for the MSXML XSLProcessor https://github.com/HtmlUnit/htmlunit/commit/77aeaa85e1fc69e929858ae700b24528275d8d07;>77aeaa8 another minor neko update Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.8.0...3.9.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-surefire/network/alerts). -- 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] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793047#comment-17793047
]
Dave Moten commented on MBUILDCACHE-76:
---
So this will happen for a single module project as well (multi-module is a
distraction).
Fundamentally the build cache doesn't work in this circumstance because no
artifacts will be rebuilt and installed to .m2 (and they do not even exist at
that version).
Why don't we just include the versions in the checksum?
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-381] - Refactor incremental detection [maven-compiler-plugin]
jorsol commented on PR #181: URL: https://github.com/apache/maven-compiler-plugin/pull/181#issuecomment-1839543867 Hi @olamy, is there any other feedback? -- 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] (MCOMPILER-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)
[
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793040#comment-17793040
]
ASF GitHub Bot commented on MCOMPILER-381:
--
jorsol commented on PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#issuecomment-1839543867
Hi @olamy, is there any other feedback?
> Refactoring needed for isDependencyChanged / Using fileExtensions
> (AbstractCompilerMojo)
>
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is
> being changed within the {{isDependencyChanged}} method. This attribute is
> also being used by the method {{hasNewFile}} which is a kind of confusing (a
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}}
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379].
> It should be investigated how this code can be made more clear and maybe
> easier to understand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-335) Better resolver errors for Artifact Not Found
[
https://issues.apache.org/jira/browse/MRESOLVER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793006#comment-17793006
]
ASF GitHub Bot commented on MRESOLVER-335:
--
cstamas opened a new pull request, #386:
URL: https://github.com/apache/maven-resolver/pull/386
Basically drop the method building text message (and build something very
basic instead). It is the application that should build proper output, as it
does have access to
org.eclipse.aether.resolution.ArtifactResolutionException#getResults and can
and should build meaningful error instead.
---
https://issues.apache.org/jira/browse/MRESOLVER-335
> Better resolver errors for Artifact Not Found
> -
>
> Key: MRESOLVER-335
> URL: https://issues.apache.org/jira/browse/MRESOLVER-335
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.0.0
>
>
> When we have many remote repositories only first
> {{ArtifactNotFoundException}} is returned, all checks for other repositories
> are hidden.
> When we have errors for many artifacts in one request - list of problematic
> artifacts is present in message and only first exception for one artifact.
> Next case is with remote repository filtering, checks for remote repository
> according to filtering also produce {{ArtifactNotFoundException}}, this is
> done at the beginning so exception is first on list.
> In logs and exception we have:
> {code}
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.pom
> [WARNING] The POM for org.apache.commons:commons-lang3:jar:4.4.4 is missing,
> no dependency information available
> Downloading from my-mirror:
> https://artifactory.../artifactory/remote-repos/org/apache/commons/commons-lang3/4.4.4/commons-lang3-4.4.4.jar
> [ERROR] Failed to execute goal on project maven-3.9: Could not resolve
> dependencies for project org.test:maven-3.9:jar:1.0.0-SNAPSHOT: Prefix org
> NOT allowed from mayrepo (https://artifactory.../artifactory/myrepo/,
> default, releases+snapshots)
> {code}
> As we see artefact was not found in {{my-mirror}}, but in error report we
> have information about not allowed prefixes - it can be confusing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MRESOLVER-335] Proposal for better errors [maven-resolver]
cstamas opened a new pull request, #386: URL: https://github.com/apache/maven-resolver/pull/386 Basically drop the method building text message (and build something very basic instead). It is the application that should build proper output, as it does have access to org.eclipse.aether.resolution.ArtifactResolutionException#getResults and can and should build meaningful error instead. --- https://issues.apache.org/jira/browse/MRESOLVER-335 -- 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-443) Integrate "configuration page generator" tool into build/site
[ https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792971#comment-17792971 ] Tamas Cservenak commented on MRESOLVER-443: --- [~michael-o] And what about this in PR? Given "build" and "site build" are two distinct Maven invocations... > Integrate "configuration page generator" tool into build/site > - > > Key: MRESOLVER-443 > URL: https://issues.apache.org/jira/browse/MRESOLVER-443 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As part of MRESOLVER-440 we got a "tool" that basically generates this page: > [https://maven.apache.org/resolver/configuration.html] > It was manually authored before, that had many issues, was laborious and was > error prone. > This tool should be integrated somehow into "site", but unsure how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-443) Integrate "configuration page generator" tool into build/site
[ https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-443: - Assignee: Tamas Cservenak > Integrate "configuration page generator" tool into build/site > - > > Key: MRESOLVER-443 > URL: https://issues.apache.org/jira/browse/MRESOLVER-443 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As part of MRESOLVER-440 we got a "tool" that basically generates this page: > [https://maven.apache.org/resolver/configuration.html] > It was manually authored before, that had many issues, was laborious and was > error prone. > This tool should be integrated somehow into "site", but unsure how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MRESOLVER-443] Integrate tool into build [maven-resolver]
cstamas opened a new pull request, #385: URL: https://github.com/apache/maven-resolver/pull/385 Simply invoke it as very last step of build to generate the documentation. Ideally, this will produce _same output_ hence there will be no side effect. But in case page is outdated the local checkout becomes dirty and would prevent release. --- https://issues.apache.org/jira/browse/MRESOLVER-443 -- 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-443) Integrate "configuration page generator" tool into build/site
[ https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792969#comment-17792969 ] ASF GitHub Bot commented on MRESOLVER-443: -- cstamas opened a new pull request, #385: URL: https://github.com/apache/maven-resolver/pull/385 Simply invoke it as very last step of build to generate the documentation. Ideally, this will produce _same output_ hence there will be no side effect. But in case page is outdated the local checkout becomes dirty and would prevent release. --- https://issues.apache.org/jira/browse/MRESOLVER-443 > Integrate "configuration page generator" tool into build/site > - > > Key: MRESOLVER-443 > URL: https://issues.apache.org/jira/browse/MRESOLVER-443 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As part of MRESOLVER-440 we got a "tool" that basically generates this page: > [https://maven.apache.org/resolver/configuration.html] > It was manually authored before, that had many issues, was laborious and was > error prone. > This tool should be integrated somehow into "site", but unsure how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-443) Integrate "configuration page generator" tool into build/site
[ https://issues.apache.org/jira/browse/MRESOLVER-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-443: -- Component/s: Resolver > Integrate "configuration page generator" tool into build/site > - > > Key: MRESOLVER-443 > URL: https://issues.apache.org/jira/browse/MRESOLVER-443 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As part of MRESOLVER-440 we got a "tool" that basically generates this page: > [https://maven.apache.org/resolver/configuration.html] > It was manually authored before, that had many issues, was laborious and was > error prone. > This tool should be integrated somehow into "site", but unsure how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-445) Simplify session handling, move out logic from session builder
[ https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-445: -- Component/s: Resolver > Simplify session handling, move out logic from session builder > -- > > Key: MRESOLVER-445 > URL: https://issues.apache.org/jira/browse/MRESOLVER-445 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Simplify session handling (copy is gone), also move out logic from session > builder to make it reusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-329] More robust IO in default tracking file manager [maven-resolver]
cstamas closed pull request #260: [MRESOLVER-329] More robust IO in default tracking file manager URL: https://github.com/apache/maven-resolver/pull/260 -- 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-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792946#comment-17792946 ] ASF GitHub Bot commented on MRESOLVER-329: -- cstamas closed pull request #260: [MRESOLVER-329] More robust IO in default tracking file manager URL: https://github.com/apache/maven-resolver/pull/260 > Make IO in DefaultTrackingFileManager more robust > - > > Key: MRESOLVER-329 > URL: https://issues.apache.org/jira/browse/MRESOLVER-329 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > There are couple of spots where implementation naively assumes is alone > running process on this world. Several user reports suggests this is not the > case, like MRESOLVER-325 or MNG-7705. Fix these spots. > Still, something is fishy, as it seems these files (all that are handled by > DefaultTrackingFileManager) are not subject to locking? This needs > investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Experiment; Fix for scope selector [maven-resolver]
cstamas commented on PR #306: URL: https://github.com/apache/maven-resolver/pull/306#issuecomment-1839044990 This experiment made no sense, closing it out. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Experiment; Fix for scope selector [maven-resolver]
cstamas closed pull request #306: Experiment; Fix for scope selector URL: https://github.com/apache/maven-resolver/pull/306 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Minor grammar edits [maven-site]
elharo merged PR #471: URL: https://github.com/apache/maven-site/pull/471 -- 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] (MJARSIGNER-73) Upgrade Apache Derby to 10.17.1.0
Pradeep Agrawal created MJARSIGNER-73: - Summary: Upgrade Apache Derby to 10.17.1.0 Key: MJARSIGNER-73 URL: https://issues.apache.org/jira/browse/MJARSIGNER-73 Project: Maven Jar Signer Plugin Issue Type: Bug Reporter: Pradeep Agrawal -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJARSIGNER-72) Parallel signing for increased speed
[
https://issues.apache.org/jira/browse/MJARSIGNER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792938#comment-17792938
]
Lennart Schedin commented on MJARSIGNER-72:
---
My plan is to implement this feature and make a Pull Request for it!
> Parallel signing for increased speed
>
>
> Key: MJARSIGNER-72
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Lennart Schedin
>Priority: Minor
> Labels: performance
>
> *Background:*
> As of June 1 2023, a new industry standard mandates the storage of private
> keys used for code signing on external hardware devices. Refer to
> [https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
> for details. Various devices, from the Thales SafeNet USB eToken (about
> $30), Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series
> (about €3) can store these keys. Cloud-based HSM solutions (like DigiCert
> KeyLocker ($90/year)) also exist.
>
> This ticket primarily targets HSM as a service but could benefit network
> attached HSM solutions as well.
>
> *Problem:*
> Using the {{jarsigner:sign}} goal it is possible to specify
> {{{}archiveDirectory{}}}, that points to a directory with many jar files.
> This is useful for signing every dependency the project has.
>
> Using the DigiCert Keylocker HSM as a service I measured that it took 240
> seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
> service is in USA. The response time of server is about 500 to 700 ms
> (without any login and without any signing).
>
> I created a quick parallel hack (using the Linux command parallel) that used
> 8 threads and it took only 31 seconds. That is: for this specific HSM service
> it scales linearly with the number of threads used.
>
> *To implement:*
> I propose to implement a parallelization for maven-jarsigner-plugin that can
> be used when signing many jar files at once.
>
> The configuration for this could be a new parameter named {{threadCount}}
> (with user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
> parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJARSIGNER-72) Parallel signing for increased speed
Lennart Schedin created MJARSIGNER-72:
-
Summary: Parallel signing for increased speed
Key: MJARSIGNER-72
URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
Project: Maven Jar Signer Plugin
Issue Type: New Feature
Affects Versions: 3.0.0
Reporter: Lennart Schedin
*Background:*
As of June 1 2023, a new industry standard mandates the storage of private keys
used for code signing on external hardware devices. Refer to
[https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
for details. Various devices, from the Thales SafeNet USB eToken (about $30),
Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series (about
€3) can store these keys. Cloud-based HSM solutions (like DigiCert
KeyLocker ($90/year)) also exist.
This ticket primarily targets HSM as a service but could benefit network
attached HSM solutions as well.
*Problem:*
Using the {{jarsigner:sign}} goal it is possible to specify
{{{}archiveDirectory{}}}, that points to a directory with many jar files. This
is useful for signing every dependency the project has.
Using the DigiCert Keylocker HSM as a service I measured that it took 240
seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
service is in USA. The response time of server is about 500 to 700 ms (without
any login and without any signing).
I created a quick parallel hack (using the Linux command parallel) that used 8
threads and it took only 31 seconds. That is: for this specific HSM service it
scales linearly with the number of threads used.
*To implement:*
I propose to implement a parallelization for maven-jarsigner-plugin that can be
used when signing many jar files at once.
The configuration for this could be a new parameter named {{threadCount}} (with
user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Apache Lucene 9.9.0 and other minor dependency bumps [maven-indexer]
mbien opened a new pull request, #337: URL: https://github.com/apache/maven-indexer/pull/337 - lucene 9.8.0 to 9.9.0 changes: https://lucene.apache.org/core/9_9_0/changes/Changes.html - this also switches javac source/target to release - didn't touch guice since it 7.0 changes namespace -- 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] (MRESOLVER-445) Simplify session handling, move out logic from session builder
[ https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-445. - Resolution: Fixed > Simplify session handling, move out logic from session builder > -- > > Key: MRESOLVER-445 > URL: https://issues.apache.org/jira/browse/MRESOLVER-445 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Simplify session handling (copy is gone), also move out logic from session > builder to make it reusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-445) Simplify session handling, move out logic from session builder
[ https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792934#comment-17792934 ] ASF GitHub Bot commented on MRESOLVER-445: -- cstamas merged PR #383: URL: https://github.com/apache/maven-resolver/pull/383 > Simplify session handling, move out logic from session builder > -- > > Key: MRESOLVER-445 > URL: https://issues.apache.org/jira/browse/MRESOLVER-445 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Simplify session handling (copy is gone), also move out logic from session > builder to make it reusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-1934: - Fix Version/s: 3.x-candidate > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.x-candidate > > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned SUREFIRE-1934: Assignee: Michael Osipov > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Assignee: Michael Osipov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
cstamas merged PR #383: URL: https://github.com/apache/maven-resolver/pull/383 -- 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] (MRESOLVER-446) Version Scheme Provider
[ https://issues.apache.org/jira/browse/MRESOLVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-446. - Assignee: Tamas Cservenak Resolution: Fixed > Version Scheme Provider > --- > > Key: MRESOLVER-446 > URL: https://issues.apache.org/jira/browse/MRESOLVER-446 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > That is able to provide version scheme, but also select it as any other > provider in resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-446) Version Scheme Provider
[ https://issues.apache.org/jira/browse/MRESOLVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792924#comment-17792924 ] ASF GitHub Bot commented on MRESOLVER-446: -- cstamas merged PR #384: URL: https://github.com/apache/maven-resolver/pull/384 > Version Scheme Provider > --- > > Key: MRESOLVER-446 > URL: https://issues.apache.org/jira/browse/MRESOLVER-446 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > That is able to provide version scheme, but also select it as any other > provider in resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-446] Introduce version scheme selector [maven-resolver]
cstamas merged PR #384: URL: https://github.com/apache/maven-resolver/pull/384 -- 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-445) Simplify session handling, move out logic from session builder
[
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792918#comment-17792918
]
ASF GitHub Bot commented on MRESOLVER-445:
--
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414099149
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Will add a warning about this above to setCache/setData methods, and will
merge this PR unless some other concern crops up.
> Simplify session handling, move out logic from session builder
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Simplify session handling (copy is gone), also move out logic from session
> builder to make it reusable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414099149
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Will add a warning about this above to setCache/setData methods, and will
merge this PR unless some other concern crops up.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-7951) Pick up resolver changes for VersionSchemeSelector
[ https://issues.apache.org/jira/browse/MNG-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7951: - Description: Resolver implemented MRESOLVER-446 and there is one component in maven-resolver-provider that needs change to have Maven fully support per-session VersionScheme. Also we should look for any other possible spots as well... This also supersedes MNG-7103 Long term plan: this would allow us to kill off Maven Version implementations, possibly reimplementing it as resolver' VersionScheme (it is nicely UT covered) with all it's flaws, and then have explicit switch between "legacy" (Maven Version) and "generic" (Resolver) version scheme, or maybe even have some new future schemes as well. was: Resolver implemented MRESOLVER-446 and there is one component in maven-resolver-provider that needs change to have Maven fully support per-session VersionScheme. Also we should look for any other possible spots as well... This also supersedes MNG-7103 > Pick up resolver changes for VersionSchemeSelector > -- > > Key: MNG-7951 > URL: https://issues.apache.org/jira/browse/MNG-7951 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9, 4.0.0 > > > Resolver implemented MRESOLVER-446 and there is one component in > maven-resolver-provider that needs change to have Maven fully support > per-session VersionScheme. Also we should look for any other possible spots > as well... > This also supersedes MNG-7103 > Long term plan: this would allow us to kill off Maven Version > implementations, possibly reimplementing it as resolver' VersionScheme (it is > nicely UT covered) with all it's flaws, and then have explicit switch between > "legacy" (Maven Version) and "generic" (Resolver) version scheme, or maybe > even have some new future schemes as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7951) Pick up resolver changes for VersionSchemeSelector
[ https://issues.apache.org/jira/browse/MNG-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7951: - Description: Resolver implemented MRESOLVER-446 and there is one component in maven-resolver-provider that needs change to have Maven fully support per-session VersionScheme. Also we should look for any other possible spots as well... This also supersedes MNG-7103 was: Resolver implemented MRESOLVER-446 and there is one component in maven-resolver-provider that needs change to have Maven fully support per-session VersionScheme. This also supersedes MNG-7103 > Pick up resolver changes for VersionSchemeSelector > -- > > Key: MNG-7951 > URL: https://issues.apache.org/jira/browse/MNG-7951 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0-alpha-9, 4.0.0 > > > Resolver implemented MRESOLVER-446 and there is one component in > maven-resolver-provider that needs change to have Maven fully support > per-session VersionScheme. Also we should look for any other possible spots > as well... > This also supersedes MNG-7103 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7951) Pick up resolver changes for VersionSchemeSelector
Tamas Cservenak created MNG-7951: Summary: Pick up resolver changes for VersionSchemeSelector Key: MNG-7951 URL: https://issues.apache.org/jira/browse/MNG-7951 Project: Maven Issue Type: Task Components: Artifacts and Repositories Reporter: Tamas Cservenak Fix For: 4.0.0-alpha-9, 4.0.0 Resolver implemented MRESOLVER-446 and there is one component in maven-resolver-provider that needs change to have Maven fully support per-session VersionScheme. This also supersedes MNG-7103 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-445) Simplify session handling, move out logic from session builder
[
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792909#comment-17792909
]
ASF GitHub Bot commented on MRESOLVER-445:
--
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of same builder
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` supplier, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
> Simplify session handling, move out logic from session builder
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Simplify session handling (copy is gone), also move out logic from session
> builder to make it reusable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of same builder
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` supplier, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of it
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` suppliers, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
--
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-445) Simplify session handling, move out logic from session builder
[
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792907#comment-17792907
]
ASF GitHub Bot commented on MRESOLVER-445:
--
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of same builder
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` suppliers, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
> Simplify session handling, move out logic from session builder
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Simplify session handling (copy is gone), also move out logic from session
> builder to make it reusable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-445) Simplify session handling, move out logic from session builder
[
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792906#comment-17792906
]
ASF GitHub Bot commented on MRESOLVER-445:
--
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of it
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` suppliers, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
> Simplify session handling, move out logic from session builder
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Simplify session handling (copy is gone), also move out logic from session
> builder to make it reusable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
cstamas commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414059162
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
Internally supplier is used, and here is why:
* create one builder
* create session S1 out of builder
* create another session S2 out of same builder
This "seemingly" trivial operation without supplier would lead that the S1
and S2 would use _same data and cache_, leading to hardly debuggable issues.
Hence, I switched internally to supplier that on each call provides new
instance (of data and cache), but IF user does use `builder.setCache(cache)` it
will become `() -> cache` suppliers, so user intentionally can achieve same
result.
I am may overthinking this, but wanted to avoid this situation (one builder
used for several session instances).
--
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-445) Simplify session handling, move out logic from session builder
[
https://issues.apache.org/jira/browse/MRESOLVER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792903#comment-17792903
]
ASF GitHub Bot commented on MRESOLVER-445:
--
gnodet commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414030542
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
This is slightly unrelated to this PR, but why do we need a
`Supplier` and not directly a `SessionData` ? Same for
`setRepositoryCacheSupplier`. I don't think they should be part of the API.
If the user wants to set the cache/session data, he will use
`setSessionData` or `setRepositoryCache`, and for the default values, we can
simply inline the default suppliers when the session is actually built.
> Simplify session handling, move out logic from session builder
> --
>
> Key: MRESOLVER-445
> URL: https://issues.apache.org/jira/browse/MRESOLVER-445
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Simplify session handling (copy is gone), also move out logic from session
> builder to make it reusable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-445] Simplify session handling, move out logic from session builder [maven-resolver]
gnodet commented on code in PR #383:
URL: https://github.com/apache/maven-resolver/pull/383#discussion_r1414030542
##
maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystemSession.java:
##
@@ -391,20 +378,20 @@ interface SessionBuilder {
SessionBuilder setData(SessionData data);
/**
- * Sets the custom session data supplier associated with this session.
+ * Sets the cache the repository system may use to save data for
future reuse during the session.
*
- * @param dataSupplier The session data supplier, may not be {@code
null}.
+ * @param cache The repository cache, may be {@code null} if none.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
+SessionBuilder setCache(RepositoryCache cache);
/**
- * Sets the cache the repository system may use to save data for
future reuse during the session.
+ * Sets the custom session data supplier associated with this session.
*
- * @param cache The repository cache, may be {@code null} if none.
+ * @param dataSupplier The session data supplier, may not be {@code
null}.
* @return This session for chaining, never {@code null}.
*/
-SessionBuilder setCache(RepositoryCache cache);
+SessionBuilder setSessionDataSupplier(Supplier
dataSupplier);
Review Comment:
This is slightly unrelated to this PR, but why do we need a
`Supplier` and not directly a `SessionData` ? Same for
`setRepositoryCacheSupplier`. I don't think they should be part of the API.
If the user wants to set the cache/session data, he will use
`setSessionData` or `setRepositoryCache`, and for the default values, we can
simply inline the default suppliers when the session is actually built.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Bump net.sourceforge.plantuml:plantuml from 1.2023.11 to 1.2023.12 [maven-site]
elharo merged PR #463: URL: https://github.com/apache/maven-site/pull/463 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.mojo:build-helper-maven-plugin from 3.4.0 to 3.5.0 [maven-site]
elharo merged PR #467: URL: https://github.com/apache/maven-site/pull/467 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Minor grammar edits [maven-site]
elharo opened a new pull request, #471: URL: https://github.com/apache/maven-site/pull/471 This fixes some simple glitches. However, I'm not sure the language accurately describes what's happening here. According to this page the last release in the 3.8.x branch is 3.9.6. -- 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-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792855#comment-17792855 ] ASF GitHub Bot commented on SUREFIRE-1934: -- michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1838668154 Also, were can I see that this applies to passed tests only? > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1838668154 Also, were can I see that this applies to passed tests only? -- 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] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with huge stderr/stdout output in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-2212.
Resolution: Fixed
Fixed with
[05322d992778dd33e2f2e41661a2e66ef7539a68|https://gitbox.apache.org/repos/asf?p=maven-surefire.git=commit=05322d992778dd33e2f2e41661a2e66ef7539a68].
> OutOfMemoryError raised when parsing files with huge stderr/stdout output in
> surefire-report-parser
> ---
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792852#comment-17792852 ] ASF GitHub Bot commented on SUREFIRE-1934: -- michael-o commented on code in PR #670: URL: https://github.com/apache/maven-surefire/pull/670#discussion_r1413880902 ## surefire-its/src/test/resources/surefire-1934-enable-out-elements/pom.xml: ## @@ -0,0 +1,64 @@ + + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + + +org.apache.maven.surefire +it-parent +1.0 +../pom.xml + + + org.apache.maven.plugins.surefire + surefire-1934-disable-out-elements + 1.0 + http://maven.apache.org + + + + junit + junit + 4.0 + + + log4j + log4j + 1.2.16 + + Review Comment: Can you please swap this for SLF4J API + Simple. Log4J is a troublesome fellow. ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. + * + * True by default. Review Comment: These two lines are redundant, Plugin Tools will take care of that. ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. + * + * True by default. + * + * @since 3.0.0 Review Comment: This should be 3.2.3 ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. Review Comment: XML > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with huge stderr/stdout output in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792851#comment-17792851
]
ASF GitHub Bot commented on SUREFIRE-2212:
--
michael-o closed pull request #687: [SUREFIRE-2212] surefire-report-parser:
parse element content only if needed to prevent OOME
URL: https://github.com/apache/maven-surefire/pull/687
> OutOfMemoryError raised when parsing files with huge stderr/stdout output in
> surefire-report-parser
> ---
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
michael-o commented on code in PR #670: URL: https://github.com/apache/maven-surefire/pull/670#discussion_r1413880902 ## surefire-its/src/test/resources/surefire-1934-enable-out-elements/pom.xml: ## @@ -0,0 +1,64 @@ + + + +http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> + 4.0.0 + + +org.apache.maven.surefire +it-parent +1.0 +../pom.xml + + + org.apache.maven.plugins.surefire + surefire-1934-disable-out-elements + 1.0 + http://maven.apache.org + + + + junit + junit + 4.0 + + + log4j + log4j + 1.2.16 + + Review Comment: Can you please swap this for SLF4J API + Simple. Log4J is a troublesome fellow. ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. + * + * True by default. Review Comment: These two lines are redundant, Plugin Tools will take care of that. ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. + * + * True by default. + * + * @since 3.0.0 Review Comment: This should be 3.2.3 ## maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java: ## @@ -679,6 +679,16 @@ public abstract class AbstractSurefireMojo extends AbstractMojo implements Suref @Parameter(property = "enableAssertions", defaultValue = "true") private boolean enableAssertions; +/** + * Flag for including/excluding system-out and system-err elements in xml reports. Review Comment: XML -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [SUREFIRE-2212] surefire-report-parser: parse element content only if needed to prevent OOME [maven-surefire]
michael-o closed pull request #687: [SUREFIRE-2212] surefire-report-parser: parse element content only if needed to prevent OOME URL: https://github.com/apache/maven-surefire/pull/687 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with a lot of std-err information in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2212:
-
Fix Version/s: 3.2.3
(was: 3.x-candidate)
> OutOfMemoryError raised when parsing files with a lot of std-err information
> in surefire-report-parser
> --
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with huge stderr/stdout output in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2212:
-
Summary: OutOfMemoryError raised when parsing files with huge stderr/stdout
output in surefire-report-parser (was: OutOfMemoryError raised when parsing
files with a lot of std-err information in surefire-report-parser)
> OutOfMemoryError raised when parsing files with huge stderr/stdout output in
> surefire-report-parser
> ---
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.3
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with a lot of std-err information in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792811#comment-17792811
]
ASF GitHub Bot commented on SUREFIRE-2212:
--
michael-o commented on PR #687:
URL: https://github.com/apache/maven-surefire/pull/687#issuecomment-1838541736
> @michael-o : thanks for the feedback. Added a corresponding unit test
The test looks reasonable. Waiting for the tests to complete.
> OutOfMemoryError raised when parsing files with a lot of std-err information
> in surefire-report-parser
> --
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.x-candidate
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2212] surefire-report-parser: parse element content only if needed to prevent OOME [maven-surefire]
michael-o commented on PR #687: URL: https://github.com/apache/maven-surefire/pull/687#issuecomment-1838541736 > @michael-o : thanks for the feedback. Added a corresponding unit test The test looks reasonable. Waiting for the tests to complete. -- 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-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792808#comment-17792808 ] ASF GitHub Bot commented on SUREFIRE-2211: -- michael-o closed pull request #689: [SUREFIRE-2211] Fix UNC classpath elements URL: https://github.com/apache/maven-surefire/pull/689 > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
michael-o closed pull request #689: [SUREFIRE-2211] Fix UNC classpath elements URL: https://github.com/apache/maven-surefire/pull/689 -- 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] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SUREFIRE-2211. Resolution: Fixed Fixed with [55ccd06a027f1693557c2a3ec3690ac91dcc59ba|https://gitbox.apache.org/repos/asf?p=maven-surefire.git=commit=55ccd06a027f1693557c2a3ec3690ac91dcc59ba]. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with a lot of std-err information in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792770#comment-17792770
]
ASF GitHub Bot commented on SUREFIRE-2212:
--
bisswanger commented on PR #687:
URL: https://github.com/apache/maven-surefire/pull/687#issuecomment-1838355882
@michael-o : thanks for the feedback.
Added a corresponding unit test
> OutOfMemoryError raised when parsing files with a lot of std-err information
> in surefire-report-parser
> --
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.x-candidate
>
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2212] surefire-report-parser: parse element content only if needed to prevent OOME [maven-surefire]
bisswanger commented on PR #687: URL: https://github.com/apache/maven-surefire/pull/687#issuecomment-1838355882 @michael-o : thanks for the feedback. Added a corresponding unit test -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792729#comment-17792729 ] ASF GitHub Bot commented on SUREFIRE-2211: -- robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838087634 I found a solution for the assumption problem. It works in my environment (changed assumeTrue to assumeFalse), so hopefully the build does run now. (https://youtrack.jetbrains.com/issue/IDEA-288919/JUnit-4-assumption-throwing-error-instead-of-ignoring-test-when-using-PowerMock-runner) > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838087634 I found a solution for the assumption problem. It works in my environment (changed assumeTrue to assumeFalse), so hopefully the build does run now. (https://youtrack.jetbrains.com/issue/IDEA-288919/JUnit-4-assumption-throwing-error-instead-of-ignoring-test-when-using-PowerMock-runner) -- 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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792725#comment-17792725
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `${revision}` and group(1) returns `revision`, without `?` the greedy
pattern `.+` will match `${revision}${sha1}` and group(1) will return
`revision}${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `${revision}` and group(1) returns `revision`, without `?` the greedy
pattern `.+` will match `${revision}${sha1}` and group(1) will return
`revision}${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
--
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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792723#comment-17792723
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `revision`, without `?` the greedy will match `revision${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792724#comment-17792724
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `revision`, without `?` the greedy pattern `.+` will match
`revision${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `revision`, without `?` the greedy pattern `.+` will match
`revision${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413529992
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -96,7 +96,7 @@ public abstract class AbstractRewritePomsPhase extends
AbstractReleasePhase impl
* Regular expression pattern matching Maven expressions (i.e. references
to Maven properties).
* The first group selects the property name the expression refers to.
*/
-private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+)\\}");
+private static final Pattern EXPRESSION_PATTERN =
Pattern.compile("\\$\\{(.+?)\\}");
Review Comment:
`.+?` means `non greedy match` , hence for `${revision}${sha1}` the pattern
matches `revision`, without `?` the greedy will match `revision${sha1`
fyi https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
--
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] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792721#comment-17792721
]
ASF GitHub Bot commented on MRELEASE-1109:
--
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413526292
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -198,7 +199,17 @@ public void setVersion(String version) {
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
Properties properties = getProperties();
if (properties != null) {
-properties.computeIfPresent(ciFriendlyPropertyName, (k, v)
-> version);
+String sha1 = properties.getProperty("sha1", "");
+String changelist = properties.getProperty("changelist",
"");
+properties.setProperty(
+ciFriendlyPropertyName,
+// assume that everybody follows the example and
properties are simply chained
+version.replaceAll(sha1,
"").replaceAll(changelist, ""));
Review Comment:
`version` is a string, `sha1` and `changelist` are properties which can be
only strings
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRELEASE-1109] Snapshot detection and support for versions like `${revision}${sha1}${changelist}` [maven-release]
mkolesnikov commented on code in PR #202:
URL: https://github.com/apache/maven-release/pull/202#discussion_r1413526292
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java:
##
@@ -198,7 +199,17 @@ public void setVersion(String version) {
AbstractRewritePomsPhase.extractPropertyFromExpression(versionElement.getTextNormalize());
Properties properties = getProperties();
if (properties != null) {
-properties.computeIfPresent(ciFriendlyPropertyName, (k, v)
-> version);
+String sha1 = properties.getProperty("sha1", "");
+String changelist = properties.getProperty("changelist",
"");
+properties.setProperty(
+ciFriendlyPropertyName,
+// assume that everybody follows the example and
properties are simply chained
+version.replaceAll(sha1,
"").replaceAll(changelist, ""));
Review Comment:
`version` is a string, `sha1` and `changelist` are properties which can be
only strings
--
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-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792717#comment-17792717 ] ASF GitHub Bot commented on SUREFIRE-2211: -- robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838050550 Seems like PowerMockRunner does not work with assumptions. I'll have to find another way to skip the test in a non Windows environment. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838050550 Seems like PowerMockRunner does not work with assumptions. I'll have to find another way to skip the test in a non Windows environment. -- 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-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792711#comment-17792711 ] ASF GitHub Bot commented on SUREFIRE-2211: -- robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838037352 Yeah, I will have a look at it. I want to exclude this test in non Windows environments and thought assumption is the way to go, like at SurefireHelperTest shouldEscapeWindowsPath, but I'm probably missing something. > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
robseidel commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838037352 Yeah, I will have a look at it. I want to exclude this test in non Windows environments and thought assumption is the way to go, like at SurefireHelperTest shouldEscapeWindowsPath, but I'm probably missing something. -- 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-2211) additionalClasspathElement with UNC path not working with Maven Failsafe Plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792709#comment-17792709 ] ASF GitHub Bot commented on SUREFIRE-2211: -- michael-o commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838031197 @robseidel Thanks! Can you have a look why the assumption fails? > additionalClasspathElement with UNC path not working with Maven Failsafe > Plugin > --- > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.3 > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
michael-o commented on PR #689: URL: https://github.com/apache/maven-surefire/pull/689#issuecomment-1838031197 @robseidel Thanks! Can you have a look why the assumption fails? -- 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
