[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144773#comment-16144773 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/161 @jon-bell Thx for contributing. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1396. -- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=99cd4f65f5f04ed8c98f446850f5f8bd7b98fc64 > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144768#comment-16144768 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user asfgit closed the pull request at: https://github.com/apache/maven-surefire/pull/161 > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1396: --- Fix Version/s: 2.20.1 > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1396: -- Assignee: Tibor Digana > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144664#comment-16144664 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 @Tibor17 I have rebased master on top of my branch, it is again up to date. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1384) Add ProviderInfo for JUnit Plattform to enable automatic provider lookup
[ https://issues.apache.org/jira/browse/SUREFIRE-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144491#comment-16144491 ] Hudson commented on SUREFIRE-1384: -- ABORTED: Integrated in Jenkins build maven-surefire-junit5 #48 (See [https://builds.apache.org/job/maven-surefire-junit5/48/]) SUREFIRE-1384: Start implemeting JUnit Plattform ProviderInfo for (britter: rev 1a7dd9b84f8462fa841e015826b44c553ff64b5e) * (add) surefire-integration-tests/src/test/resources/junit-plattform/pom.xml * (add) surefire-integration-tests/src/test/resources/junit-plattform/src/test/java/junitplattform/BasicTest.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java * (add) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnitPlattformIT.java > Add ProviderInfo for JUnit Plattform to enable automatic provider lookup > > > Key: SUREFIRE-1384 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1384 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > > In order to enable automatic provider lookup for JUnit Plattform/JUnit 5, we > need to add the corresponding ProviderInfo implementation to > AbstractSurefireMojo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[ https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144478#comment-16144478 ] ASF GitHub Bot commented on SUREFIRE-1383: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @JoelNGeorge @owenfarrell Pls let me run the build and next steps. > dependenciesToScan Does Not Leverage Classpath Elements > > > Key: SUREFIRE-1383 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Owen Farrell > Fix For: Backlog > > Attachments: scanned-dependencies-sample.zip > > > The configuration attribute relies solely on installed > artifacts. This is an issue when the targeted dependencies were built as part > of the current session. The net result is that stale artifacts are used (i.e. > if the dependency has changed since it was last installed) or the tests are > not executed at all (if the dependency has not been previously installed. > Attached is a sample project that illustrates this issue: > Given I have a multi-module project >And the first module built includes test classes as part of the project > artifact >And subsequent modules scan the first for unit tests to execute > When I execute the _*test*_ goal (prior to any install) > Then the build should succeed >And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1391) System Property variables processed twice in calculation of effective properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144476#comment-16144476
]
ASF GitHub Bot commented on SUREFIRE-1391:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/159
@andrew-j-cohen
Please close this PR. It was already merged in Surefire project.
> System Property variables processed twice in calculation of effective
> properties
>
>
> Key: SUREFIRE-1391
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1391
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Andrew Cohen
>Assignee: Michael Osipov
>Priority: Trivial
> Fix For: 2.20.1
>
> Attachments:
> 0001-SUREFIRE-1391-Eliminate-redundant-call-to-process-sy.patch
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> System property variables are processed twice in the calculation of effective
> properties. There is obviously no adverse impact on behavior, just
> unnecessary processing.
> {code:java}
> static SurefireProperties calculateEffectiveProperties( Properties
> systemProperties,
> Map String> systemPropertyVariables,
> Properties
> userProperties, SurefireProperties props )
> {
> SurefireProperties result = new SurefireProperties();
> result.copyPropertiesFrom( systemProperties );
> result.copyPropertiesFrom( props );
> copyProperties( result, systemPropertyVariables );
> copyProperties( result, systemPropertyVariables );
> // We used to take all of our system properties and dump them in with
> the
> // user specified properties for SUREFIRE-121, causing SUREFIRE-491.
> // Not gonna do THAT any more... instead, we only propagate those
> system properties
> // that have been explicitly specified by the user via -Dkey=value on
> the CLI
> result.copyPropertiesFrom( userProperties );
> return result;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144409#comment-16144409 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/161 @jon-bell Ok, now your IT passed. I will run whole test set now. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144406#comment-16144406
]
Tibor Digana commented on SUREFIRE-1264:
Flaky tests fail in the build which must be fixed.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MJDEPS-6) -cp should not duplicated classes/files to analyze
[
https://issues.apache.org/jira/browse/MJDEPS-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJDEPS-6.
---
Resolution: Fixed
Fix Version/s: 3.1.0
Fixed in [r1806510|http://svn.apache.org/viewvc?rev=1806510=rev]
> -cp should not duplicated classes/files to analyze
> --
>
> Key: MJDEPS-6
> URL: https://issues.apache.org/jira/browse/MJDEPS-6
> Project: MJDEPS
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: 3.1.0
>
>
> Documentation says:
> {noformat}
> Usage: jdeps
> where can be a pathname to a .class file, a directory, a JAR file,
> or a fully-qualified class name. Possible options include:
> ...
> -cp-classpath Specify where to find class files
> {noformat}
> It is not required to repeat the elements from as part of -cp. This
> will reduce the total commandline.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJDEPS-3) Can't handle long classpath
[ https://issues.apache.org/jira/browse/MJDEPS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144368#comment-16144368 ] Robert Scholte commented on MJDEPS-3: - I've asked for advice on this issue and there's no solution to prevent long classpaths with JDK8. With JDK 9 we could use a ToolProvider and there will be an RFE to support \@argfiles. I was able to reduce to length by implementing MJDEPS-6, which will probably help a lot in your case, although I'm not sure if it'll be enough. > Can't handle long classpath > --- > > Key: MJDEPS-3 > URL: https://issues.apache.org/jira/browse/MJDEPS-3 > Project: MJDEPS > Issue Type: Bug > Environment: Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Clas Forsberg >Priority: Critical > Attachments: error.txt > > > When running I got this error > Cannot run program "C:\java\jdk8\jre\..\bin\jdeps.exe": CreateProcess > error=206, The filename or extension is too long > Mavan debug log attached -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MJDEPS-6) -cp should not duplicated classes/files to analyze
Robert Scholte created MJDEPS-6:
---
Summary: -cp should not duplicated classes/files to analyze
Key: MJDEPS-6
URL: https://issues.apache.org/jira/browse/MJDEPS-6
Project: MJDEPS
Issue Type: Improvement
Reporter: Robert Scholte
Assignee: Robert Scholte
Documentation says:
{noformat}
Usage: jdeps
where can be a pathname to a .class file, a directory, a JAR file,
or a fully-qualified class name. Possible options include:
...
-cp-classpath Specify where to find class files
{noformat}
It is not required to repeat the elements from as part of -cp. This
will reduce the total commandline.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1384) Add ProviderInfo for JUnit Plattform to enable automatic provider lookup
[ https://issues.apache.org/jira/browse/SUREFIRE-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144335#comment-16144335 ] ASF GitHub Bot commented on SUREFIRE-1384: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/162 @britter Done. I added enforcer configuration. I hope it will be fine. Let me know if you have something to do for me. Sometimes I am without internet connection for several days or I am connected a half day or so. > Add ProviderInfo for JUnit Plattform to enable automatic provider lookup > > > Key: SUREFIRE-1384 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1384 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > > In order to enable automatic provider lookup for JUnit Plattform/JUnit 5, we > need to add the corresponding ProviderInfo implementation to > AbstractSurefireMojo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1384) Add ProviderInfo for JUnit Plattform to enable automatic provider lookup
[ https://issues.apache.org/jira/browse/SUREFIRE-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144326#comment-16144326 ] ASF GitHub Bot commented on SUREFIRE-1384: -- Github user asfgit closed the pull request at: https://github.com/apache/maven-surefire/pull/162 > Add ProviderInfo for JUnit Plattform to enable automatic provider lookup > > > Key: SUREFIRE-1384 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1384 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > > In order to enable automatic provider lookup for JUnit Plattform/JUnit 5, we > need to add the corresponding ProviderInfo implementation to > AbstractSurefireMojo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJDEPS-5) Require Java 7
[ https://issues.apache.org/jira/browse/MJDEPS-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144313#comment-16144313 ] Hudson commented on MJDEPS-5: - SUCCESS: Integrated in Jenkins build maven-plugins #9082 (See [https://builds.apache.org/job/maven-plugins/9082/]) [MJDEPS-5] Require Java 7 (rfscholte: [http://svn.apache.org/viewvc/?view=rev=1806504]) * (edit) maven-jdeps-plugin/pom.xml > Require Java 7 > -- > > Key: MJDEPS-5 > URL: https://issues.apache.org/jira/browse/MJDEPS-5 > Project: MJDEPS > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.1.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144310#comment-16144310 ] ASF GitHub Bot commented on MNG-6127: - Github user mkrizmanic closed the pull request at: https://github.com/apache/maven/pull/113 > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic >Assignee: Robert Scholte > Fix For: 3.5.1 > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144309#comment-16144309 ] ASF GitHub Bot commented on MNG-6127: - Github user mkrizmanic commented on the issue: https://github.com/apache/maven/pull/113 Merged to master: https://github.com/apache/maven/commit/f1ed6592b1c701834d1377fade6cdb382a63bbf4 > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic >Assignee: Robert Scholte > Fix For: 3.5.1 > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MJDEPS-5) Require Java 7
[ https://issues.apache.org/jira/browse/MJDEPS-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJDEPS-5. --- Resolution: Fixed Fixed in [r1806504|http://svn.apache.org/viewvc?rev=1806504=rev] > Require Java 7 > -- > > Key: MJDEPS-5 > URL: https://issues.apache.org/jira/browse/MJDEPS-5 > Project: MJDEPS > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.1.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MJDEPS-5) Require Java 7
Robert Scholte created MJDEPS-5: --- Summary: Require Java 7 Key: MJDEPS-5 URL: https://issues.apache.org/jira/browse/MJDEPS-5 Project: MJDEPS Issue Type: Improvement Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 3.1.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144246#comment-16144246
]
Tibor Digana commented on SUREFIRE-1264:
[~Prifiz]
[~valyok]
I have pushed a branch {{SUREFIRE-1264_2}} with a fix.
Can you please build the project on your side and use the version
{{2.21-SNAPSHOT}} in your project and give me a feedback with your test result.
Please build Surefire project like this:
{{mvn install -DskipTests}}
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1384) Add ProviderInfo for JUnit Plattform to enable automatic provider lookup
[ https://issues.apache.org/jira/browse/SUREFIRE-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16144194#comment-16144194 ] ASF GitHub Bot commented on SUREFIRE-1384: -- Github user britter commented on the issue: https://github.com/apache/maven-surefire/pull/162 @Tibor17 any news on this? > Add ProviderInfo for JUnit Plattform to enable automatic provider lookup > > > Key: SUREFIRE-1384 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1384 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > > In order to enable automatic provider lookup for JUnit Plattform/JUnit 5, we > need to add the corresponding ProviderInfo implementation to > AbstractSurefireMojo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MRESOLVER-31) OSGi metadata
Elliotte Rusty Harold created MRESOLVER-31: -- Summary: OSGi metadata Key: MRESOLVER-31 URL: https://issues.apache.org/jira/browse/MRESOLVER-31 Project: Maven Resolver Issue Type: Improvement Components: resolver Affects Versions: Maven Artifact Resolver 1.1.0 Environment: all Reporter: Elliotte Rusty Harold The MANIFEST.MF for the HTTP transport (and I suspect the file transport too though I haven't popped it open and looked yet) does not have OSGI metadata: elharo-macbookair99:Downloads elharo$ more META-INF/MANIFEST.MF Manifest-Version: 1.0 Implementation-Title: Maven Artifact Resolver Transport HTTP Implementation-Version: 1.1.0 Built-By: mosipov Specification-Vendor: The Apache Software Foundation Created-By: Apache Maven 3.5.0 Implementation-URL: https://maven.apache.org/resolver/maven-resolver-t ransport-http/ Implementation-Vendor: The Apache Software Foundation Automatic-Module-Name: org.apache.maven.resolver.transport.http Implementation-Vendor-Id: org.apache.maven.resolver Build-Jdk: 1.7.0_121 Specification-Title: Maven Artifact Resolver Transport HTTP Specification-Version: 1.1 Archiver-Version: Plexus Archiver Adding this would be extremely helpful for anyone who wants to use this in an Eclipse plugin. E.g. Bundle-ManifestVersion: 2 Bundle-Name: org.apache.maven.resolver.transport.http Bundle-RequiredExecutionEnvironment: J2SE-1.5, J2SE-1.4 Bundle-SymbolicName: org.apache.maven.resolver.transport.http Bundle-Vendor: apache.org Bundle-Version: 1.1.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MJDEPS-2) Only execute for java projects with sources, i.e jar and war
[ https://issues.apache.org/jira/browse/MJDEPS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJDEPS-2. --- Resolution: Not A Problem Code checks for classes-directory, that's sufficient enough. > Only execute for java projects with sources, i.e jar and war > > > Key: MJDEPS-2 > URL: https://issues.apache.org/jira/browse/MJDEPS-2 > Project: MJDEPS > Issue Type: New Feature >Reporter: Robert Scholte >Assignee: Robert Scholte > > To be able to define this plugin usefully in a parent pom or multimodule pom, > the plugin should be aware when it should be executed. I can only think of > the packaging types jar and war right now. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MJDEPS-1) Make the plugin thread safe
[
https://issues.apache.org/jira/browse/MJDEPS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJDEPS-1:
Fix Version/s: 3.1.0
> Make the plugin thread safe
> ---
>
> Key: MJDEPS-1
> URL: https://issues.apache.org/jira/browse/MJDEPS-1
> Project: MJDEPS
> Issue Type: New Feature
>Reporter: Quentin Caillard
>Assignee: Robert Scholte
> Fix For: 3.1.0
>
>
> {noformat}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in
> AriadNEXT-DEMAT-WS-Gesrem:
> [WARNING] org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> [WARNING] *
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MJDEPS-4) Upgrade commons-lang to be able to run with JDK9
[
https://issues.apache.org/jira/browse/MJDEPS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJDEPS-4:
Fix Version/s: 3.1.0
> Upgrade commons-lang to be able to run with JDK9
>
>
> Key: MJDEPS-4
> URL: https://issues.apache.org/jira/browse/MJDEPS-4
> Project: MJDEPS
> Issue Type: Improvement
>Reporter: Mark Derricutt
>Assignee: Robert Scholte
> Fix For: 3.1.0
>
>
> When running this plugin with Java9 it fails with
> {code}
> Caused by: java.lang.ExceptionInInitializerError
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.getJDepsExecutable(AbstractJDepsMojo.java:359)
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.execute(AbstractJDepsMojo.java:196)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
> at java.base/java.lang.String.substring(String.java:1885)
> at
> org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133)
> at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
> ... 24 more
> {code}
> Like other plugins upgrading commons-lang will fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJDEPS-4) Upgrade commons-lang to be able to run with JDK9
[
https://issues.apache.org/jira/browse/MJDEPS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143727#comment-16143727
]
Hudson commented on MJDEPS-4:
-
UNSTABLE: Integrated in Jenkins build maven-plugins #9081 (See
[https://builds.apache.org/job/maven-plugins/9081/])
[MJDEPS-4] Upgrade commons-lang to be able to run with JDK9 (rfscholte:
[http://svn.apache.org/viewvc/?view=rev=1806434])
* (edit) maven-jdeps-plugin/pom.xml
* (add) maven-jdeps-plugin/src/it/basic
* (add) maven-jdeps-plugin/src/it/basic/invoker.properties
* (add) maven-jdeps-plugin/src/it/basic/pom.xml
* (add) maven-jdeps-plugin/src/it/basic/src
* (add) maven-jdeps-plugin/src/it/basic/src/main
* (add) maven-jdeps-plugin/src/it/basic/src/main/java
* (add) maven-jdeps-plugin/src/it/basic/src/main/java/Main.java
* (edit) maven-jdeps-plugin/src/it/unsupported-api_main/invoker.properties
* (edit) maven-jdeps-plugin/src/it/unsupported-api_test/invoker.properties
* (edit)
maven-jdeps-plugin/src/main/java/org/apache/maven/plugin/jdeps/AbstractJDepsMojo.java
> Upgrade commons-lang to be able to run with JDK9
>
>
> Key: MJDEPS-4
> URL: https://issues.apache.org/jira/browse/MJDEPS-4
> Project: MJDEPS
> Issue Type: Improvement
>Reporter: Mark Derricutt
>Assignee: Robert Scholte
>
> When running this plugin with Java9 it fails with
> {code}
> Caused by: java.lang.ExceptionInInitializerError
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.getJDepsExecutable(AbstractJDepsMojo.java:359)
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.execute(AbstractJDepsMojo.java:196)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
> at java.base/java.lang.String.substring(String.java:1885)
> at
> org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133)
> at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
> ... 24 more
> {code}
> Like other plugins upgrading commons-lang will fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJDEPS-4) Upgrade commons-lang to be able to run with JDK9
[
https://issues.apache.org/jira/browse/MJDEPS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143690#comment-16143690
]
Robert Scholte commented on MJDEPS-4:
-
Fixed in [r1806434|http://svn.apache.org/viewvc?rev=1806434=rev]
> Upgrade commons-lang to be able to run with JDK9
>
>
> Key: MJDEPS-4
> URL: https://issues.apache.org/jira/browse/MJDEPS-4
> Project: MJDEPS
> Issue Type: Improvement
>Reporter: Mark Derricutt
>Assignee: Robert Scholte
>
> When running this plugin with Java9 it fails with
> {code}
> Caused by: java.lang.ExceptionInInitializerError
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.getJDepsExecutable(AbstractJDepsMojo.java:359)
> at
> org.apache.maven.plugin.jdeps.AbstractJDepsMojo.execute(AbstractJDepsMojo.java:196)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
> at java.base/java.lang.String.substring(String.java:1885)
> at
> org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133)
> at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
> ... 24 more
> {code}
> Like other plugins upgrading commons-lang will fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJDEPS-1) Make the plugin thread safe
[
https://issues.apache.org/jira/browse/MJDEPS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143680#comment-16143680
]
Hudson commented on MJDEPS-1:
-
SUCCESS: Integrated in Jenkins build maven-plugins #9080 (See
[https://builds.apache.org/job/maven-plugins/9080/])
[MJDEPS-1] Make the plugin thread safe (rfscholte:
[http://svn.apache.org/viewvc/?view=rev=1806430])
* (edit)
maven-jdeps-plugin/src/main/java/org/apache/maven/plugin/jdeps/JDKInternalsMojo.java
* (edit)
maven-jdeps-plugin/src/main/java/org/apache/maven/plugin/jdeps/TestJDKInternalsMojo.java
> Make the plugin thread safe
> ---
>
> Key: MJDEPS-1
> URL: https://issues.apache.org/jira/browse/MJDEPS-1
> Project: MJDEPS
> Issue Type: New Feature
>Reporter: Quentin Caillard
>Assignee: Robert Scholte
>
> {noformat}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in
> AriadNEXT-DEMAT-WS-Gesrem:
> [WARNING] org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> [WARNING] *
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJDEPS-4) Upgrade commons-lang to be able to run with JDK9
Robert Scholte created MJDEPS-4:
---
Summary: Upgrade commons-lang to be able to run with JDK9
Key: MJDEPS-4
URL: https://issues.apache.org/jira/browse/MJDEPS-4
Project: MJDEPS
Issue Type: Improvement
Reporter: Mark Derricutt
Assignee: Robert Scholte
When running this plugin with Java9 it fails with
{code}
Caused by: java.lang.ExceptionInInitializerError
at
org.apache.maven.plugin.jdeps.AbstractJDepsMojo.getJDepsExecutable(AbstractJDepsMojo.java:359)
at
org.apache.maven.plugin.jdeps.AbstractJDepsMojo.execute(AbstractJDepsMojo.java:196)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
at java.base/java.lang.String.substring(String.java:1885)
at
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1133)
at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
... 24 more
{code}
Like other plugins upgrading commons-lang will fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJDEPS-1) Make the plugin thread safe
[
https://issues.apache.org/jira/browse/MJDEPS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143666#comment-16143666
]
Robert Scholte commented on MJDEPS-1:
-
Fixed in [r1806430|http://svn.apache.org/viewvc?rev=1806430=rev]
> Make the plugin thread safe
> ---
>
> Key: MJDEPS-1
> URL: https://issues.apache.org/jira/browse/MJDEPS-1
> Project: MJDEPS
> Issue Type: New Feature
>Reporter: Quentin Caillard
>Assignee: Robert Scholte
>
> {noformat}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in
> AriadNEXT-DEMAT-WS-Gesrem:
> [WARNING] org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> [WARNING] *
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[ https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143667#comment-16143667 ] Zlika commented on MNG-6276: Idempotent is a mathematical word for functions. It's definition (fof = f) does not apply here from my point of view. Wikipedia has a "Deterministic compilation" page that starts with: "Deterministic compilation, also known as reproducible builds...". I'm not fond of "deterministic" because it would mean that current builds are "undeterministic", which is wrong (a timestamp IS deterministic, it just depends on the time you read it). I think "reproducible" is a better term, and yes I may be Debian-biased but there are leading the subject, and you can find lots of other people and organization using this name, e.g. the EFF, Tor project, Tail project, Yocto project, Fedora, OpenSUSE, the Core Infrastructure Initiative of the Linux foundation... Concerning EOL, having a cross-platform reproducible build may be much more complex to achieve, and may not be possible in some cases (because for example you have different profiles in your pom for Linux/Windows/Mac, or you have a native library, etc...). As a first step, it would be much more simple to limit the reproducibility to the same OS/architecture. > Support reproducible builds > --- > > Key: MNG-6276 > URL: https://issues.apache.org/jira/browse/MNG-6276 > Project: Maven > Issue Type: New Feature > Components: core, General >Reporter: Paolo Sacconier > > A venerable build system like maven should support full build reproduibilty > (i.e. producing bit a bit identical binaries from the same source). > As initiatives like https://reproducible-builds.org gain traction and the > news of the recent Debian policy change to mandate this build behavior (see > https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature > that needs to be considered for inclusion into maven core. > There is an indipendent ongoing effort to support this feature and the author > stated that he has found interest from maven project to integrate his work: > https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883 > I hope this issue helps kickstart the effort. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MJDEPS-1) Make the plugin thread safe
[
https://issues.apache.org/jira/browse/MJDEPS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MJDEPS-1:
---
Assignee: Robert Scholte
> Make the plugin thread safe
> ---
>
> Key: MJDEPS-1
> URL: https://issues.apache.org/jira/browse/MJDEPS-1
> Project: MJDEPS
> Issue Type: New Feature
>Reporter: Quentin Caillard
>Assignee: Robert Scholte
>
> {noformat}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in
> AriadNEXT-DEMAT-WS-Gesrem:
> [WARNING] org.apache.maven.plugins:maven-jdeps-plugin:3.0.0
> [WARNING] *
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[
https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143619#comment-16143619
]
Robert Scholte commented on MNG-6276:
-
I'm not convinced that "reproducabile builds" is the most widely used term,
especially if https://reproducible-builds.org/ is used for that information.
IMHO the term is not complete enough. {{Idempotent}} is used within the http
world and describes how GET, POST, PUT etc should behave.
I like the word {{deterministic}}, which is indeed more common word and better
reflects its purpose.
The annotation is a way for the developer to say: this plugin supports X.
Without it, it could still support it, but there's no way to verify it. If you
want to ensure a deterministic build, all your plugins should support it. For
instance: in case of maven-resource-plugin, you MUST specify an EOL-String to
ensure that line-endings of text-files don't depend on the OS.
> Support reproducible builds
> ---
>
> Key: MNG-6276
> URL: https://issues.apache.org/jira/browse/MNG-6276
> Project: Maven
> Issue Type: New Feature
> Components: core, General
>Reporter: Paolo Sacconier
>
> A venerable build system like maven should support full build reproduibilty
> (i.e. producing bit a bit identical binaries from the same source).
> As initiatives like https://reproducible-builds.org gain traction and the
> news of the recent Debian policy change to mandate this build behavior (see
> https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature
> that needs to be considered for inclusion into maven core.
> There is an indipendent ongoing effort to support this feature and the author
> stated that he has found interest from maven project to integrate his work:
> https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883
> I hope this issue helps kickstart the effort.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6276) Support reproducible builds
[ https://issues.apache.org/jira/browse/MNG-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143478#comment-16143478 ] Zlika commented on MNG-6276: "reproducible builds" is indeed the most widely used term, I don't think it would be a good idea to user another one. Moreover, the mathematical term "idempotent" has a different meaning: if Maven is considered as a "build" function with source code as its input and jar file as its output, idempotent would mean that we can apply Maven on the output (the jar file) of a previous invocation and have the same output, which is not the case. I totally agree with Hervé's first comment to create a property name like project.build.reproducible and use it the same way as we use project.build.sourceEncoding. It could be a boolean with False as its default value. The next step would be to identify the plugins that create unreproducible bits and create JIRA issues for them. I don't know the benefits of an annotation for this kind of feature, but keep in mind that this is different than thread-safeting: a plugin IS thread-safe or not, whereas a plugin COULD be configured not to generate unreproducible bits. A wiki page may help to document and organize the information on this subject. > Support reproducible builds > --- > > Key: MNG-6276 > URL: https://issues.apache.org/jira/browse/MNG-6276 > Project: Maven > Issue Type: New Feature > Components: core, General >Reporter: Paolo Sacconier > > A venerable build system like maven should support full build reproduibilty > (i.e. producing bit a bit identical binaries from the same source). > As initiatives like https://reproducible-builds.org gain traction and the > news of the recent Debian policy change to mandate this build behavior (see > https://reproducible.alioth.debian.org/blog/posts/121/), this seems a feature > that needs to be considered for inclusion into maven core. > There is an indipendent ongoing effort to support this feature and the author > stated that he has found interest from maven project to integrate his work: > https://github.com/Zlika/reproducible-build-maven-plugin/issues/6#issuecomment-325005883 > I hope this issue helps kickstart the effort. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
