[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)
