[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096909#comment-16096909
]
Matt Nelson commented on MNG-6240:
--
Could the 3.5.1 fix version be updated with a projected release date?
https://issues.apache.org/jira/projects/MNG/versions/12338964
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.5.1
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-277) Upgrade maven-dependency-tree to 3.x
Robert Scholte created MENFORCER-277:
Summary: Upgrade maven-dependency-tree to 3.x
Key: MENFORCER-277
URL: https://issues.apache.org/jira/browse/MENFORCER-277
Project: Maven Enforcer Plugin
Issue Type: Improvement
Affects Versions: 1.4.1
Reporter: Robert Scholte
As part of MENFORCER-264 maven-dependency-tree should be upgraded. This would
imply switching from the M2 {{DependencyTreeBuilder}} to M2/M3
{{DependencyGraphBuilder}}.
However, {{DependencyGraphBuilder}} uses {{ProjectDependenciesResolver}}, which
provides the *resolved* graph instead of a raw tree.
This is a requirement for both {{DependencyConvergence}} and
{{RequireUpperBoundDeps}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096709#comment-16096709
]
Guillaume Boué commented on SUREFIRE-1376:
--
[~tibor17] That would be great.
I think the path to the test project needs to be created at runtime, so that
the actual absolute path to the test project is created by JRE which handles
long paths already. For the execution part, probably we can reuse Maven shared
utils {{CommandLineUtils}} to launch {{mvn}} ourselves and check error stream.
> "The forked VM terminated without properly saying goodbye" when running
> Surefire in a very deep project structure on Windows
>
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows'
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{\\?\}}, [as documented
> on
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath],
> makes the test run again correctly. I've attached a possible patch with this
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │ pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
> when running the ITs on the Assembly Plugin.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16096378#comment-16096378
]
Hudson commented on SUREFIRE-1302:
--
SUCCESS: Integrated in Jenkins build maven-surefire-dev #10 (See
[https://builds.apache.org/job/maven-surefire-dev/10/])
SUREFIRE-1302_4 (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git&a=commit&h=c7e0582bbc181b2d63901367f4d12613640352a7])
* (add)
surefire-api/src/test/java/org/apache/maven/surefire/util/ReflectionUtilsTest.java
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/PropertiesWrapper.java
* (add)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/SystemUtils.java
* (edit) maven-failsafe-plugin/pom.xml
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/BooterSerializer.java
* (edit)
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1295AttributeJvmCrashesToTestsIT.java
* (edit)
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/BooterDeserializerStartupConfigurationTest.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/util/ReflectionUtils.java
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/Classpath.java
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/BooterConstants.java
* (edit) pom.xml
* (add)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/ProcessInfo.java
* (add)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/PpidChecker.java
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/BooterDeserializer.java
* (edit)
surefire-booter/src/test/java/org/apache/maven/surefire/booter/JUnit4SuiteTest.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/CommandReader.java
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java
* (edit)
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/BooterDeserializerProviderConfigurationTest.java
* (edit) surefire-api/pom.xml
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/FileReporterUtils.java
* (edit) surefire-api/src/test/java/org/apache/maven/JUnit4SuiteTest.java
* (edit) maven-surefire-plugin/pom.xml
* (edit) maven-surefire-plugin/src/site/apt/examples/shutdown.apt.vm
* (delete)
surefire-api/src/test/java/org/apache/maven/surefire/util/internal/SystemUtilsTest.java
* (edit) surefire-booter/pom.xml
* (add)
surefire-booter/src/test/java/org/apache/maven/surefire/booter/SystemUtilsTest.java
* (edit) maven-surefire-common/pom.xml
* (edit) maven-surefire-report-plugin/pom.xml
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
* (add)
surefire-booter/src/test/java/org/apache/maven/surefire/booter/PpidCheckerTest.java
* (delete)
surefire-api/src/main/java/org/apache/maven/surefire/util/internal/SystemUtils.java
> 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: 2017-05-18T05-48-08_685-jvmRun1.dumpstream,
> surefire-gclog.log, surefire-logs,
> 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
[jira] [Commented] (SUREFIRE-1376) "The forked VM terminated without properly saying goodbye" when running Surefire in a very deep project structure on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096318#comment-16096318
]
Tibor Digana commented on SUREFIRE-1376:
[~gboue]
[~tunaki]
I will have spare time these days. I want to write an IT.
> "The forked VM terminated without properly saying goodbye" when running
> Surefire in a very deep project structure on Windows
>
>
> Key: SUREFIRE-1376
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1376
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
> Environment: Windows
>Reporter: Guillaume Boué
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: SUREFIRE-1376-prefix.patch
>
>
> When Surefire is ran on a project under a very long path (exceeding Windows'
> {{MAX_PATH}}), the invocation fails with
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?
> {noformat}
> In the generated dumpstream, there is
> {noformat}
> # Created on 2017-05-28T10:17:09.474
> Error: Unable to access jarfile
> C:\Users\Guillaume\Desktop\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\surefire-longpath-test-with-windows\target\surefire\surefirebooter2512478076549179739.jar
> {noformat}
> The problem is that the path to the JAR file exceeds the maximum path length
> of 260 characters, and so it cannot be accessed.
> Prepending the path to the JAR file with {{\\?\}}, [as documented
> on
> MSDN|https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath],
> makes the test run again correctly. I've attached a possible patch with this
> approach (SUREFIRE-1376-prefix.patch, that also handles UNC pathnames), but
> perhaps there is a better way to tackle this problem.
> In order to reproduce this, it is possible to create a project under lots of
> different subdirectories, something like:
> {noformat}
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> └───surefire-longpath-test-with-windows
> │ pom.xml
> │
> └───src
> └───test
> └───java
> └───Test.java
> {noformat}
> As a side-note, this issue is behind the current Jenkins failures on
> [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows|https://builds.apache.org/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows/3702/]
> when running the ITs on the Assembly Plugin.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1394) Missing final tag for Surefire 2.20
[ https://issues.apache.org/jira/browse/SUREFIRE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096312#comment-16096312 ] Michael Osipov commented on SUREFIRE-1394: -- Absolutely. > Missing final tag for Surefire 2.20 > --- > > Key: SUREFIRE-1394 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1394 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Affects Versions: 2.20 >Reporter: Emmanuel Bourg >Priority: Trivial > > Hi, > The Git repository is missing the final tag for the release 2.20, there are > only the 3 vote tags. Could you add it please? > Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1394) Missing final tag for Surefire 2.20
[ https://issues.apache.org/jira/browse/SUREFIRE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096302#comment-16096302 ] Tibor Digana commented on SUREFIRE-1394: In the future it would be better to skip repeating the vote of the same version and better delete a tag and roll a new version vote. It's the same like with Maven core. > Missing final tag for Surefire 2.20 > --- > > Key: SUREFIRE-1394 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1394 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Affects Versions: 2.20 >Reporter: Emmanuel Bourg >Priority: Trivial > > Hi, > The Git repository is missing the final tag for the release 2.20, there are > only the 3 vote tags. Could you add it please? > Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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=16096292#comment-16096292
]
Tibor Digana edited comment on SUREFIRE-1373 at 7/21/17 2:08 PM:
-
It looks like both groups run one after another.
[Here|https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilder.java#L579]
{{suiteSuites, suiteClasses}} should be encapsulated in one ParentRunner and
{{createSuite( notParallelRunners )}} in second ParentRunner.
If you guys want to contribute, you can check it out and run the build {{mvn
install}}. Not sure if the tests fail after this change.
was (Author: tibor17):
It looks like both groups run one after another.
[Here|https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilder.java#L579]
{{suiteSuites, suiteClasses}} should be encapsulated in one ParentRunner and
{{createSuite( notParallelRunners )}}.
If you guys want to contribute, you can check it out and run the build {{mvn
install}}. Not sure if the tests fail after this change.
> 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
> Fix For: 2.20.1
>
>
> 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.4.14#64029)
[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=16096292#comment-16096292
]
Tibor Digana commented on SUREFIRE-1373:
It looks like both groups run one after another.
[Here|https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilder.java#L579]
{{suiteSuites, suiteClasses}} should be encapsulated in one ParentRunner and
{{createSuite( notParallelRunners )}}.
If you guys want to contribute, you can check it out and run the build {{mvn
install}}. Not sure if the tests fail after this change.
> 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
> Fix For: 2.20.1
>
>
> 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.4.14#64029)
[jira] [Commented] (SUREFIRE-1394) Missing final tag for Surefire 2.20
[ https://issues.apache.org/jira/browse/SUREFIRE-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096284#comment-16096284 ] Tibor Digana commented on SUREFIRE-1394: In the release time this did not make sense to me because the tag in POM.xml could not match the final tag name in git. I can create it upon the third vote which is that last and valid. > Missing final tag for Surefire 2.20 > --- > > Key: SUREFIRE-1394 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1394 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Affects Versions: 2.20 >Reporter: Emmanuel Bourg >Priority: Trivial > > Hi, > The Git repository is missing the final tag for the release 2.20, there are > only the 3 vote tags. Could you add it please? > Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SCM-486) Support signed tags for git when releasing
[
https://issues.apache.org/jira/browse/SCM-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096203#comment-16096203
]
Oliver Lietz commented on SCM-486:
--
[~khmarbaise], can we get this feature for {{maven-scm-provider-gitexe}} and
{{maven-scm-provider-jgit}} finally?
> Support signed tags for git when releasing
> --
>
> Key: SCM-486
> URL: https://issues.apache.org/jira/browse/SCM-486
> Project: Maven SCM
> Issue Type: Wish
> Components: maven-scm-provider-gitexe
>Reporter: Chris Searle
> Fix For: 1.x
>
> Attachments: SCM-486_sign_git_tags.diff
>
>
> When tagging the release - it would be nice if the git plugin for scm allowed
> for an annotated and signed tag rather than just an annotated tag.
> If this is already possible then either I need a pointer to the correct doc
> ;) (or it would be nice if the doc covered how to configure it).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MJAVADOC-471) When aggregator filters out artifacts of current reactor projects, only the primary artifact is considered
[
https://issues.apache.org/jira/browse/MJAVADOC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-471:
Fix Version/s: (was: 3.0.0)
> When aggregator filters out artifacts of current reactor projects, only the
> primary artifact is considered
> --
>
> Key: MJAVADOC-471
> URL: https://issues.apache.org/jira/browse/MJAVADOC-471
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Matt Benson
> Attachments: MJAVADOC-471.patch.txt
>
>
> given project structure
> {code}
> foo-parent
> - foo-child-1
> - foo-child-2
> {code}
> If {{foo-child-2}} depends on the {{tests}} artifact of {{foo-child-1}} the
> build still breaks, despite the changes made for MJAVADOC-437 .
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16096056#comment-16096056
]
DM edited comment on SUREFIRE-1373 at 7/21/17 9:33 AM:
---
Can someone let me know if my below understanding is correct or not after
reading the documentation:-
All the classes marked with {{@NotThreadSafe}} runs in a single thread one
after another. This single thread executing {{@NotThreadSafe}} test classes
runs after all the threads executing tests in parallel are finished.
was (Author: tuk):
What is the behavior are the classes marked with @NotThreadSafe running in a
single thread after the all the parallel executions are finished?
Can someone let me know if my below understanding is correct or not after
reading the documentation:-
All the classes marked with {{@NotThreadSafe}} runs in a single thread one
after another. This single thread executing {{@NotThreadSafe}} test classes
runs after all the threads executing tests in parallel are finished.
> 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
> Fix For: 2.20.1
>
>
> 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.4.14#64029)
[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=16096056#comment-16096056
]
DM commented on SUREFIRE-1373:
--
What is the behavior are the classes marked with @NotThreadSafe running in a
single thread after the all the parallel executions are finished?
Can someone let me know if my below understanding is correct or not after
reading the documentation:-
All the classes marked with {{@NotThreadSafe}} runs in a single thread one
after another. This single thread executing {{@NotThreadSafe}} test classes
runs after all the threads executing tests in parallel are finished.
> 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
> Fix For: 2.20.1
>
>
> 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.4.14#64029)
[jira] [Updated] (MNGSITE-313) Add documentation for MNG-1493 (referencing POM file in )
[ https://issues.apache.org/jira/browse/MNGSITE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Brychcy updated MNGSITE-313: - Attachment: MNGSITE-313-maven-site.patch > Add documentation for MNG-1493 (referencing POM file in ) > - > > Key: MNGSITE-313 > URL: https://issues.apache.org/jira/browse/MNGSITE-313 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Till Brychcy > Attachments: MNGSITE-313-maven-site.patch > > > I yesterday learned about the feature implemented in > https://issues.apache.org/jira/browse/MNG-1493 > and noted it is not documented in the POM reference > https://maven.apache.org/pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNGSITE-313) Add documentation for MNG-1493 (referencing POM file in )
Till Brychcy created MNGSITE-313: Summary: Add documentation for MNG-1493 (referencing POM file in ) Key: MNGSITE-313 URL: https://issues.apache.org/jira/browse/MNGSITE-313 Project: Maven Project Web Site Issue Type: Improvement Reporter: Till Brychcy I yesterday learned about the feature implemented in https://issues.apache.org/jira/browse/MNG-1493 and noted it is not documented in the POM reference https://maven.apache.org/pom.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
