[jira] [Commented] (MNG-6232) Version range is not resolved correctly
[ https://issues.apache.org/jira/browse/MNG-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009238#comment-16009238 ] Karl Heinz Marbaise commented on MNG-6232: -- The simple answer to this is: {{1.8.0-alpha-2}} is less than {{1.8}} which fulfils the requirement of the given range {{[1.7,1.8)}}. A little more in detail. The version range {{[1.7,1.8)}} just means greater or equal {{1.7}} and less than {{1.8}}. By definition {{1.8-alpha-2}} is less than {{1.8}} which means in consequence less than {{1.8}} which will fulfil the requirement. This can be checked by using {code} java -jar apache-maven-3.3.3/lib/maven-artifact-3.3.3.jar 1.8 1.8-alpha-2 {code} (Works with newer Maven versions as well). This will printout: {code} Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.8 == 1.8 1.8 > 1.8-alpha-2 2. 1.8-alpha-2 == 1.8-alpha-2 {code} > Version range is not resolved correctly > --- > > Key: MNG-6232 > URL: https://issues.apache.org/jira/browse/MNG-6232 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Marek Budyn > Attachments: pom.xml > > > When dependency is specified as range, e.g slf4j-api version [1.7, 1.8) as in > provided pom.xml, one would expect to resolver to version 1.7.X (e.g. > 1.7.25). Instead maven resolves version 1.8.0-alpha 2. > Output of command 'mvn dependenct:tree' on provided pom.xml: > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building project 1.0.0-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ project --- > [INFO] test:project:jar:1.0.0-SNAPSHOT > [INFO] \- org.slf4j:slf4j-api:jar:1.8.0-alpha2:compile > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 1.273 s > [INFO] Finished at: 2017-05-12T23:37:02+02:00 > [INFO] Final Memory: 13M/225M > [INFO] > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (SUREFIRE-1373) Tests annotated with @NotThreadSafe are not executed in isolation
[ https://issues.apache.org/jira/browse/SUREFIRE-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1373: -- Assignee: Tibor Digana > Tests annotated with @NotThreadSafe are not executed in isolation > - > > Key: SUREFIRE-1373 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1373 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Sebastian Kirsch >Assignee: Tibor Digana > > The [surefire > documentation|http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html] > states that > bq. you can apply the JCIP annotation @net.jcip.annotations.NotThreadSafe on > the Java class of JUnit test (pure test class, Suite, Parameterized, etc.) in > order to execute it in single Thread instance. The Thread has name > maven-surefire-plugin@NotThreadSafe and it is executed at the end of the test > run. > However, the thread is run in parallel to the other tests being executed, > which contradicts the documentation and defeats the purpose of running tests > sequentially in a single thread. > See https://github.com/sebastiankirsch/surefire-nonthreadsafe for a test case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1373) Tests annotated with @NotThreadSafe are not executed in isolation
[ https://issues.apache.org/jira/browse/SUREFIRE-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009247#comment-16009247 ] Tibor Digana commented on SUREFIRE-1373: [~apache-bugzi...@sebastian-kirsch.org] [~sebastiankirsch] I will explain and I want to have your feedback. I want to make sure I understand your problem. You configure parameter {{parallel}}. So you do it with a purpose to speed up the execution. The annotation {{@NotThreadSafe}} executes all such classes in one particular Thread. So it means you have two groups of threads: a bunch of parallel Threads, and one single Thread running another bunch of classes one by one. This is expected. Please confirm {{@NotThreadSafe}} classes are executed one by one in a sequence. These two groups do not necessarily mean they have to run in a sequence. They can run in parallel which is the purpose to speed up the test-set. What matters is that tests which cannot run in multiple threads, because they and their classes are not threadsafe, are isolated in single Thread. > Tests annotated with @NotThreadSafe are not executed in isolation > - > > Key: SUREFIRE-1373 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1373 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Sebastian Kirsch >Assignee: Tibor Digana > > The [surefire > documentation|http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html] > states that > bq. you can apply the JCIP annotation @net.jcip.annotations.NotThreadSafe on > the Java class of JUnit test (pure test class, Suite, Parameterized, etc.) in > order to execute it in single Thread instance. The Thread has name > maven-surefire-plugin@NotThreadSafe and it is executed at the end of the test > run. > However, the thread is run in parallel to the other tests being executed, > which contradicts the documentation and defeats the purpose of running tests > sequentially in a single thread. > See https://github.com/sebastiankirsch/surefire-nonthreadsafe for a test case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1373) Tests annotated with @NotThreadSafe are not executed in isolation
[ https://issues.apache.org/jira/browse/SUREFIRE-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009247#comment-16009247 ] Tibor Digana edited comment on SUREFIRE-1373 at 5/13/17 10:15 AM: -- [~apache-bugzi...@sebastian-kirsch.org] [~sebastiankirsch] I will explain and I want to have your feedback. I want to make sure I understand your problem. You configure parameter {{parallel}}. So you do it with a purpose to speed up the execution. The annotation {{@NotThreadSafe}} executes all such classes in one particular Thread. So it means you have two groups of threads: a bunch of parallel Threads, and one single Thread running another bunch of classes one by one. This is expected. Please confirm {{@NotThreadSafe}} classes are executed one by one in a sequence. These two groups do not necessarily mean they have to run in a sequence. They can run in parallel which is the purpose to speed up the test-set execution. What matters is that tests which cannot run in multiple threads, because they and their classes are not threadsafe, are isolated in single Thread. was (Author: tibor17): [~apache-bugzi...@sebastian-kirsch.org] [~sebastiankirsch] I will explain and I want to have your feedback. I want to make sure I understand your problem. You configure parameter {{parallel}}. So you do it with a purpose to speed up the execution. The annotation {{@NotThreadSafe}} executes all such classes in one particular Thread. So it means you have two groups of threads: a bunch of parallel Threads, and one single Thread running another bunch of classes one by one. This is expected. Please confirm {{@NotThreadSafe}} classes are executed one by one in a sequence. These two groups do not necessarily mean they have to run in a sequence. They can run in parallel which is the purpose to speed up the test-set. What matters is that tests which cannot run in multiple threads, because they and their classes are not threadsafe, are isolated in single Thread. > Tests annotated with @NotThreadSafe are not executed in isolation > - > > Key: SUREFIRE-1373 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1373 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Sebastian Kirsch >Assignee: Tibor Digana > > The [surefire > documentation|http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/fork-options-and-parallel-execution.html] > states that > bq. you can apply the JCIP annotation @net.jcip.annotations.NotThreadSafe on > the Java class of JUnit test (pure test class, Suite, Parameterized, etc.) in > order to execute it in single Thread instance. The Thread has name > maven-surefire-plugin@NotThreadSafe and it is executed at the end of the test > run. > However, the thread is run in parallel to the other tests being executed, > which contradicts the documentation and defeats the purpose of running tests > sequentially in a single thread. > See https://github.com/sebastiankirsch/surefire-nonthreadsafe for a test case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6232) Version range is not resolved correctly
[ https://issues.apache.org/jira/browse/MNG-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009355#comment-16009355 ] Marek Budyn commented on MNG-6232: -- Well, I can imagine that maven artifact resolves versions as you shown, still I believe that this not what one would expect. First, 1.8-alpha seems to be quite different version branch. Even if you specify range like [1.0,2.0), 2.0-alpha artifacts (which tend to be incompatible with 1.0) will be included, which I believe is totally unwanted behavior Secondly, there is (as far as I know) no other way to prevent alpha artifacts to be excluded, except of putting everywhere -alpha qualifier (which looks bizarre when you specify all ranges like [1.0,2.0-alpha); [1.7,1.8-alpha) Finally, one can never be sure if someone will not release 'alpha' artifact breaking all dependencies. So, as I was unable to find kind of 'official' guide about version resolution for alpha/beta stuff, could you, please, guide me to the official spec of version resolution in maven? Like if putting -alpha at the right side of version ranges will always prevent higher branch artifacts from being included? And maybe there should be a way to exclude alpha/beta/snapshot releases in version range which I provided ? > Version range is not resolved correctly > --- > > Key: MNG-6232 > URL: https://issues.apache.org/jira/browse/MNG-6232 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.3 >Reporter: Marek Budyn > Attachments: pom.xml > > > When dependency is specified as range, e.g slf4j-api version [1.7, 1.8) as in > provided pom.xml, one would expect to resolver to version 1.7.X (e.g. > 1.7.25). Instead maven resolves version 1.8.0-alpha 2. > Output of command 'mvn dependenct:tree' on provided pom.xml: > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building project 1.0.0-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ project --- > [INFO] test:project:jar:1.0.0-SNAPSHOT > [INFO] \- org.slf4j:slf4j-api:jar:1.8.0-alpha2:compile > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 1.273 s > [INFO] Finished at: 2017-05-12T23:37:02+02:00 > [INFO] Final Memory: 13M/225M > [INFO] > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[ https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009419#comment-16009419 ] Tibor Digana commented on SUREFIRE-1302: [~opeyrusse] Can you pls build {{SUREFIRE-1302}} branch {{mvn -DskipTests install}} and test it with your project? I will override the branch and add parameter soon and then I want to change the documentation. Yet the ping timeout is adaptive. Adding parameter takes time because several classes and reflection has to be changed. https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=shortlog;h=refs/heads/SUREFIRE-1302 > Surefire does not wait long enough for the forked VM and assumes it to be dead > -- > > Key: SUREFIRE-1302 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1302 > Project: Maven Surefire > Issue Type: Request > Components: Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Yuriy Zaplavnov >Assignee: Tibor Digana > Fix For: 2.20.1 > > Attachments: > surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip, > tests_log_01.txt, tests_log_02.txt > > > This issue happens because surefire kills the forked container if it times > out waiting for the 'ping'. > In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded > constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method: > {code} > private static ScheduledFuture listenToShutdownCommands( CommandReader > reader ) > { > reader.addShutdownListener( createExitHandler( reader ) ); > AtomicBoolean pingDone = new AtomicBoolean( true ); > reader.addNoopListener( createPingHandler( pingDone ) ); > return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone, > reader ), >0,PING_TIMEOUT_IN_SECONDS, > SECONDS ); > } > {code} > to create ScheduledFuture. > In some of the cases the forked container might respond a bit later than it's > expected and surefire kills it > {code} > private static Runnable createPingJob( final AtomicBoolean pingDone, final > CommandReader reader ) > { > return new Runnable() > { > public void run() > { > boolean hasPing = pingDone.getAndSet( false ); > if ( !hasPing ) > { > exit( 1, KILL, reader, true ); > } > } > }; > } > {code} > As long as we need to terminate it anyway, It would be really helpful if the > problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with > the ability to specify the value from maven-surefire-plugin. > It would help to configure this timeout based on needs and factors of the > projects where surefire runs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MJAVADOC-482) -sourceclasspath should not be added if it does not exist
Archimedes Trajano created MJAVADOC-482: --- Summary: -sourceclasspath should not be added if it does not exist Key: MJAVADOC-482 URL: https://issues.apache.org/jira/browse/MJAVADOC-482 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 2.10.4 Reporter: Archimedes Trajano On pom and ear projects where there is usually no target/classes the plugin should not add `-sourceclasspath` It fails on JDK8 javadoc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MJAVADOC-482) -sourceclasspath should not be added if it does not exist
[ https://issues.apache.org/jira/browse/MJAVADOC-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Archimedes Trajano closed MJAVADOC-482. --- Resolution: Not A Problem > -sourceclasspath should not be added if it does not exist > - > > Key: MJAVADOC-482 > URL: https://issues.apache.org/jira/browse/MJAVADOC-482 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 2.10.4 >Reporter: Archimedes Trajano > > On pom and ear projects where there is usually no target/classes the plugin > should not add `-sourceclasspath` It fails on JDK8 javadoc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)