[GitHub] [maven-surefire] ajohnstonTE commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
ajohnstonTE commented on a change in pull request #267: [SUREFIRE-1741] JUnit5:
Detect failed containers
URL: https://github.com/apache/maven-surefire/pull/267#discussion_r370920432
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -185,6 +188,13 @@ private SimpleReportEntry createReportEntry(
TestIdentifier testIdentifier,
stw, elapsedTime, reason, systemProperties );
}
+private boolean isFailedContainer( TestIdentifier testIdentifier,
+ TestExecutionResult testExecutionResult )
+{
+return testIdentifier.isContainer() && testExecutionResult != null
Review comment:
I'll switch to a static import, but I do need the null check. The method
directly below this one passes a null value for a `testExecutionResult` (which
ultimately makes its way over to here):
https://github.com/apache/maven-surefire/pull/267/files/38ad13f5a6a628282064d1b0976e1ea69a135b0e#diff-ad07b0c74885ecb3d687dcc85495e390R198-R201
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] ajohnstonTE commented on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers
ajohnstonTE commented on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers URL: https://github.com/apache/maven-surefire/pull/267#issuecomment-578384784 Will do This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MRESOLVER-98) resolver ant task doesn't appear to obey dependencyManagement
Jay Kahrman created MRESOLVER-98: Summary: resolver ant task doesn't appear to obey dependencyManagement Key: MRESOLVER-98 URL: https://issues.apache.org/jira/browse/MRESOLVER-98 Project: Maven Resolver Issue Type: Bug Components: ant tasks Affects Versions: ant-tasks-1.2.0 Reporter: Jay Kahrman We have a dependency in our pom which has dependencies that don't specify an upper bound to the version range. To avoid getting different versions in every build we use a dependencyManagement section in the POM to lock down the version. This works via the maven 3 CLI, and via the old ant-tasks utility we were using (). The maven-resolver-ant-tasks jar doesn't appear to obey the dependencyManagement section, however. I'm not sure is this is related to MRESOLVER-33 and/or MRESOLVER-10 and if updating maven-resolver-ant-tasks to depend on Maven Resolver 1.4.0 would solve the problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 commented on issue #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257#issuecomment-578341085 Closed in favor of #267 . This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 closed pull request #257: [SUREFIRE-1727] junitplatform: handle all containers
Tibor17 closed pull request #257: [SUREFIRE-1727] junitplatform: handle all containers URL: https://github.com/apache/maven-surefire/pull/257 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers URL: https://github.com/apache/maven-surefire/pull/267#discussion_r370877245 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -396,6 +396,43 @@ public void runDisplayNameTest() throws Exception assertEquals( "73$71 ✔", reportEntries.get( 0 ).getNameText() ); } +@Test Review comment: this test looks good! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5:
Detect failed containers
URL: https://github.com/apache/maven-surefire/pull/267#discussion_r370871042
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -185,6 +188,13 @@ private SimpleReportEntry createReportEntry(
TestIdentifier testIdentifier,
stw, elapsedTime, reason, systemProperties );
}
+private boolean isFailedContainer( TestIdentifier testIdentifier,
+ TestExecutionResult testExecutionResult )
+{
+return testIdentifier.isContainer() && testExecutionResult != null
Review comment:
The call of callback method with `null` in `TestExecutionListener` does not
make sense. Acctually, the Javadoc on `TestExecutionListener` does not say
anything about passing the null to the method parameter.
Here static import of whole `TestExecutionResult.Status.FAILED` whould make
the line brief.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5:
Detect failed containers
URL: https://github.com/apache/maven-surefire/pull/267#discussion_r370871042
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -185,6 +188,13 @@ private SimpleReportEntry createReportEntry(
TestIdentifier testIdentifier,
stw, elapsedTime, reason, systemProperties );
}
+private boolean isFailedContainer( TestIdentifier testIdentifier,
+ TestExecutionResult testExecutionResult )
+{
+return testIdentifier.isContainer() && testExecutionResult != null
Review comment:
The call of callback method with `null` in `TestExecutionListener` does not
make sense. Eventhough the Javadoc on `TestExecutionListener` does not say
anything about passing the null to the method parameter.
Here static import of whole `TestExecutionResult.Status.FAILED` whould make
the line brief.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
Tibor17 commented on a change in pull request #267: [SUREFIRE-1741] JUnit5:
Detect failed containers
URL: https://github.com/apache/maven-surefire/pull/267#discussion_r370868639
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -173,8 +175,9 @@ private SimpleReportEntry createReportEntry(
TestIdentifier testIdentifier,
{
classText = null;
}
-String methodName = testIdentifier.isTest() ? classMethodName[2] :
null;
-String methodText = testIdentifier.isTest() ? classMethodName[3] :
null;
+boolean isFailedContainer = isFailedContainer( testIdentifier,
testExecutionResult );
+String methodName = ( isFailedContainer || testIdentifier.isTest() ) ?
classMethodName[2] : null;
Review comment:
You do not have to use brackets in `( isFailedContainer ||
testIdentifier.isTest() )`. There is no collision between boolean and String in
this case.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Issue Comment Deleted] (MDEP-204) go-offline fails to resolve artifact available in maven reactor
[ https://issues.apache.org/jira/browse/MDEP-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Marwell updated MDEP-204: -- Comment: was deleted (was: Any ETA for MDEP v3.1.2? Thanks :) [~michael-o] > Consider that this is a volunteer project, none of us gets paid for this. Well yes, of course. But even issues with a patch attached sometimes are not solved. There's nothing a user could do. ) > go-offline fails to resolve artifact available in maven reactor > --- > > Key: MDEP-204 > URL: https://issues.apache.org/jira/browse/MDEP-204 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 2.0, 2.1 > Environment: maven 2.1.0 >Reporter: Stevo Slavić >Assignee: Robert Scholte >Priority: Major > Fix For: 3.1.2 > > Attachments: mvn-dependency-go-offline-failing-example.zip > > Time Spent: 40m > Remaining Estimate: 0h > > Attached is example project, for which IMO dependency:go-offline should be > able to resolve all dependencies as they are only intermodule dependencies > within same multimodule project which haven't been installed yet but are > available in maven reactor so can be considered as resolvable in offline mode > - instead dependency:go-offline fails to resolve these dependencies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atle Tokle updated SUREFIRE-1747:
-
Attachment: demo.zip
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
> Attachments: demo.zip
>
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atle Tokle updated SUREFIRE-1747:
-
Attachment: (was: demo.zip)
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
> Attachments: demo.zip
>
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023279#comment-17023279
]
Atle Tokle commented on SUREFIRE-1747:
--
[~tibordigana] See [^demo.zip]
Run: mvn clean verify -Prepackage-before
That is default behaviour for spring-boot-maven-plugin. The
maven-failsafe-plugin discovers the test-class, but run no test, and give no
warnings that something is wrong
Run: mvn clean verify -Prepackage-after
Now the spring-boot-maven-plugin is executed after the maven-failsafe-plugin,
and the test is run.
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
> Attachments: demo.zip
>
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atle Tokle updated SUREFIRE-1747:
-
Attachment: demo.zip
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
> Attachments: demo.zip
>
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6854) Maven/Spring/MVC Web app - error cannot TalendJob (third party Talend jar)
[
https://issues.apache.org/jira/browse/MNG-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6854.
---
Resolution: Invalid
This is not a support forum. Go to the users list or stackoverflow.
> Maven/Spring/MVC Web app - error cannot TalendJob (third party Talend jar)
> --
>
> Key: MNG-6854
> URL: https://issues.apache.org/jira/browse/MNG-6854
> Project: Maven
> Issue Type: Bug
> Components: Errors, IDEs
>Affects Versions: 3.1.0
> Environment: Eclipse, JavaSE1.8, jre1.8.0_201, Maven, Tomcat (version
> 7.2.2 embedded), Talend 6.4, Windows 10
>Reporter: ray passage
>Priority: Major
> Labels: newbie
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Maven/Java newbie here.
> I'm developing a Spring/MVC/Maven Web app in Eclipse. The use case is for
> the app to call Talend jobs on an adhoc basis with parameters. The user
> enters time frame information (years, months) on a form page. Everything
> worked (form, validation, model, configuration, error checking, etc) until I
> added the required Talend jars. Some background - I successfully created a
> simple Web app in Eclipse that has the same use case. For this app, I needed
> to place the Talend jars into the WEB-INF\lib folder. For various reasons, I
> need to build a Web app that uses Spring/MVC/Maven technologies.
> I loaded all the required Talend jars into the WEB-INF\lib folder (exactly
> like I did with the previous Web app). I ran ran a successful Maven clean
> install. But running the embedded Tomcat (version 7.2.2) produced this error:
> [ERROR] COMPILATION ERROR :
> [ERROR]C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[13]
> error: package talenddev1.job_gl_master_ad_hoc_0_3 does not exist
> [ERROR]
> C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[141,7]
> error: cannot find symbol.
> I then followed the steps from this site:
> [https://cleanprogrammer.net/adding-3rd-party-jar-to-maven-projects/] to add
> the third party jars to Maven projects (installed the jar into the local
> repository, added repository and dependency into the pom.xml, etc)
> Running the embedded Tomcat produced this error:
> [ERROR] COMPILATION ERROR :
> [ERROR]
> C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[155,16]
> error: cannot access TalendJob
> TalendJob is located in the UserValidator.java:
> job_GL_Master_Ad_Hoc TalendJob=new job_GL_Master_Ad_Hoc();
> String[] context=new String[] \{params...}
> TalendJob.runJob(context);
>
> I realize this maybe a Talend issue so I've been also working with the Talend
> community.
> Please provide some help on this issue and let me know if you need more
> information.
> Thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1741) Exceptions in parameterized test sources are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023212#comment-17023212
]
Albert Johnston commented on SUREFIRE-1741:
---
I opened a PR with tests for the problem and a fix for it as well. But just
before I opened the PR, I noticed there's already a PR open that fixes the same
root problem, for a different Jira issue. And it does it better (it reports
them as test errors rather than test failures, and one other thing that's
harder to explain), and with less code. But for the sake of at least including
the additional tests, I still opened my PR.
My PR: [https://github.com/apache/maven-surefire/pull/267]
Other PR: [https://github.com/apache/maven-surefire/pull/257]
Other Issue: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Exceptions in parameterized test sources are ignored
>
>
> Key: SUREFIRE-1741
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1741
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire
> Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.5.1
> * JDK 11.0.5
> * Maven 3.6.1
>
> If the following code is run, either for Surefire or Failsafe, only two of
> the test methods are logged as having been detected at all. The third one is
> completely ignored as if it didn't exist.
> {code:java}
> public class ExampleTest {
> @Test
> public void shouldRunAndPassAsExpected() {
> }
> public static Stream nothing() {
> return Stream.of(Arguments.arguments());
> }
> @ParameterizedTest
> @MethodSource("nothing")
> public void shouldRunAndFailAsExpected() {
> Assertions.fail();
> }
> static Stream throwException() {
> if (true) throw new RuntimeException("Stop");
> return Stream.of(Arguments.arguments());
> }
> @ParameterizedTest
> @MethodSource("throwException")
> void willNotBeLoggedAsFailingDespiteNotRunning() {
> Assertions.fail();
> }
> }
> {code}
> This is particularly obvious if the first two test methods are commented out,
> as running mvn test will log that 0 tests were run.
>
> In case it helps, here's the output I'm seeing when running it with the first
> two tests commented out:
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running ExampleIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s
> - in ExampleIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023188#comment-17023188
]
Michael Osipov commented on WAGON-575:
--
:( The default retry handler does not contain any logging so this is a blind
flight. Do you think you good set a breakpoint on the the handler as see
whether it is called at all?
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project
[jira] [Created] (MNG-6854) Maven/Spring/MVC Web app - error cannot TalendJob (third party Talend jar)
ray passage created MNG-6854:
Summary: Maven/Spring/MVC Web app - error cannot TalendJob (third
party Talend jar)
Key: MNG-6854
URL: https://issues.apache.org/jira/browse/MNG-6854
Project: Maven
Issue Type: Bug
Components: Errors, IDEs
Affects Versions: 3.1.0
Environment: Eclipse, JavaSE1.8, jre1.8.0_201, Maven, Tomcat (version
7.2.2 embedded), Talend 6.4, Windows 10
Reporter: ray passage
Maven/Java newbie here.
I'm developing a Spring/MVC/Maven Web app in Eclipse. The use case is for the
app to call Talend jobs on an adhoc basis with parameters. The user enters
time frame information (years, months) on a form page. Everything worked
(form, validation, model, configuration, error checking, etc) until I added the
required Talend jars. Some background - I successfully created a simple Web
app in Eclipse that has the same use case. For this app, I needed to place the
Talend jars into the WEB-INF\lib folder. For various reasons, I need to build
a Web app that uses Spring/MVC/Maven technologies.
I loaded all the required Talend jars into the WEB-INF\lib folder (exactly like
I did with the previous Web app). I ran ran a successful Maven clean install.
But running the embedded Tomcat (version 7.2.2) produced this error:
[ERROR] COMPILATION ERROR :
[ERROR]C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[13]
error: package talenddev1.job_gl_master_ad_hoc_0_3 does not exist
[ERROR]
C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[141,7]
error: cannot find symbol.
I then followed the steps from this site:
[https://cleanprogrammer.net/adding-3rd-party-jar-to-maven-projects/] to add
the third party jars to Maven projects (installed the jar into the local
repository, added repository and dependency into the pom.xml, etc)
Running the embedded Tomcat produced this error:
[ERROR] COMPILATION ERROR :
[ERROR]
C:\Documents\TalendAdHoc\src\main\java\com\validator\UserValidator.java:[155,16]
error: cannot access TalendJob
TalendJob is located in the UserValidator.java:
job_GL_Master_Ad_Hoc TalendJob=new job_GL_Master_Ad_Hoc();
String[] context=new String[] \{params...}
TalendJob.runJob(context);
I realize this maybe a Talend issue so I've been also working with the Talend
community.
Please provide some help on this issue and let me know if you need more
information.
Thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1036) fix javadoc for JDK 8
[
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022922#comment-17022922
]
Hudson commented on MRELEASE-1036:
--
Build failed in Jenkins: Maven TLP » maven-release » master #49
See https://builds.apache.org/job/maven-box/job/maven-release/job/master/49/
> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running {{mvn verify site -Preporting}} with JDK 8, the project fails
> due to javadoc errors: this makes releasing the release plugin with JDK 8
> impossible.
> Notice that you might also see stacktraces caused by
> {{org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find
> org.eclipse.m2e:lifecycle-mapping:pom:1.0.0}}: these one can be ignored
> because they are only warning (not a blocker) and will be fixed with MPIR-375
> once released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRELEASE-1036) fix javadoc for JDK 8
[
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-1036.
Assignee: Robert Scholte (was: Herve Boutemy)
Resolution: Fixed
Fixed in
[09cc421e21be44cc6335839738886459a5e35a1c|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=09cc421e21be44cc6335839738886459a5e35a1c]
Thanks for the patch!
> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running {{mvn verify site -Preporting}} with JDK 8, the project fails
> due to javadoc errors: this makes releasing the release plugin with JDK 8
> impossible.
> Notice that you might also see stacktraces caused by
> {{org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find
> org.eclipse.m2e:lifecycle-mapping:pom:1.0.0}}: these one can be ignored
> because they are only warning (not a blocker) and will be fixed with MPIR-375
> once released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1036) fix javadoc for JDK 8
[
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022913#comment-17022913
]
Robert Scholte commented on MRELEASE-1036:
--
Let me merge it, it is already an improvement and AFAIK it fixes the problem of
this issue. [~hboutemy] can reopen it if he wants with his wishes.
> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running {{mvn verify site -Preporting}} with JDK 8, the project fails
> due to javadoc errors: this makes releasing the release plugin with JDK 8
> impossible.
> Notice that you might also see stacktraces caused by
> {{org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find
> org.eclipse.m2e:lifecycle-mapping:pom:1.0.0}}: these one can be ignored
> because they are only warning (not a blocker) and will be fixed with MPIR-375
> once released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-release] rfscholte merged pull request #33: [MRELEASE-1036] Fix JavaDoc for JDK 8
rfscholte merged pull request #33: [MRELEASE-1036] Fix JavaDoc for JDK 8 URL: https://github.com/apache/maven-release/pull/33 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022909#comment-17022909
]
Michael Medin commented on WAGON-575:
-
Here is the log from httpclient:
[DEBUG] Using transporter WagonTransporter with priority -1.0 for REDACTED
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for REDACTED
Downloading from REDACTED: REDACTED
[DEBUG] CookieSpec selected: compatibility
[DEBUG] Connection request: [route: \{s}->https://REDACTED:443][total kept
alive: 0; route allocated: 0 of 20; total allocated: 0 of 40]
[DEBUG] Connection leased: [id: 0][route: \{s}->https://REDACTED:443][total
kept alive: 0; route allocated: 1 of 20; total allocated: 1 of 40]
[DEBUG] Opening connection \{s}->https://REDACTED:443
[DEBUG] Connecting to REDACTED/REDACTED:443
[DEBUG] Connecting socket to REDACTED/REDACTED:443 with timeout 0
[DEBUG] Enabled protocols: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1]
[DEBUG] Enabled cipher suites:[TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
[DEBUG] Starting handshake
[DEBUG] Secure session established
[DEBUG] negotiated protocol: TLSv1.2
[DEBUG] negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[DEBUG] peer principal: CN=REDACTED, OU=Domain Control Validated
[DEBUG] peer alternative names: [REDACTED, REDACTED]
[DEBUG] issuer principal: CN=Starfield Secure Certificate Authority - G2,
OU=http://certs.starfieldtech.com/repository/, O="Starfield Technologies,
Inc.", L=Scottsdale, ST=Arizona, C=US
[DEBUG] Connection established REDACTED:51034<->REDACTED:443
[DEBUG] http-outgoing-0: set socket timeout to 180
[DEBUG] Executing request GET REDACTED HTTP/1.1
[DEBUG] Target auth state: UNCHALLENGED
[DEBUG] Proxy auth state: UNCHALLENGED
[DEBUG] http-outgoing-0 >> GET REDACTED HTTP/1.1
[DEBUG] http-outgoing-0 >> Cache-control: no-cache
[DEBUG] http-outgoing-0 >> Cache-store: no-store
[DEBUG] http-outgoing-0 >> Pragma: no-cache
[DEBUG] http-outgoing-0 >> User-Agent: Apache-Maven/3.6.2 (Java 11.0.4; Windows
10 10.0)
[DEBUG] http-outgoing-0 >> Host: REDACTED
[DEBUG] http-outgoing-0 >> Connection: Keep-Alive
[DEBUG] http-outgoing-0 >> Accept-Encoding: gzip,deflate
[DEBUG] http-outgoing-0 >> "GET REDACTED HTTP/1.1[\r][\n]"
[DEBUG] http-outgoing-0 >> "Cache-control: no-cache[\r][\n]"
[DEBUG] http-outgoing-0 >> "Cache-store: no-store[\r][\n]"
[DEBUG] http-outgoing-0 >> "Pragma: no-cache[\r][\n]"
[DEBUG] http-outgoing-0 >> "User-Agent: Apache-Maven/3.6.2 (Java 11.0.4;
Windows 10 10.0)[\r][\n]"
[DEBUG] http-outgoing-0 >> "Host: REDACTED[\r][\n]"
[DEBUG] http-outgoing-0 >> "Connection: Keep-Alive[\r][\n]"
[DEBUG] http-outgoing-0 >> "Accept-Encoding: gzip,deflate[\r][\n]"
[DEBUG] http-outgoing-0 >> "[\r][\n]"
[DEBUG] http-outgoing-0 << "HTTP/1.1 200 OK[\r][\n]"
[DEBUG] http-outgoing-0 << "Server: nginx/1.15.9 (Ubuntu)[\r][\n]"
[DEBUG] http-outgoing-0 << "Date: Fri, 24 Jan 2020 06:02:16 GMT[\r][\n]"
[DEBUG] http-outgoing-0 << "Content-Type: application/java-archive[\r][\n]"
[DEBUG] http-outgoing-0 << "Content-Length: 946377354[\r][\n]"
[DEBUG] http-outgoing-0 << "Connection: keep-alive[\r][\n]"
[DEBUG] http-outgoing-0 << "Keep-Alive: timeout=5[\r][\n]"
[DEBUG] http-outgoing-0 << "X-Content-Type-Options: nosniff[\r][\n]"
[DEBUG] http-outgoing-0 << "Content-Security-Policy: sandbox allow-forms
[jira] [Commented] (MRELEASE-1036) fix javadoc for JDK 8
[
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022908#comment-17022908
]
Carlos Chacin commented on MRELEASE-1036:
-
[~hboutemy] [~rfscholte] thanks for the PR review, should I create and attach a
patch based on the PR?
> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running {{mvn verify site -Preporting}} with JDK 8, the project fails
> due to javadoc errors: this makes releasing the release plugin with JDK 8
> impossible.
> Notice that you might also see stacktraces caused by
> {{org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find
> org.eclipse.m2e:lifecycle-mapping:pom:1.0.0}}: these one can be ignored
> because they are only warning (not a blocker) and will be fixed with MPIR-375
> once released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022866#comment-17022866
]
Tibor Digana edited comment on SUREFIRE-1745 at 1/24/20 11:03 AM:
--
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds_
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds_ has different behavior - see
doc.
Maybe you can implement this feature of a global timeout. You have to make the
reseach of course. IMO the _Computer_ or _Request_ should be implemented and
passed to the JUnitCore in Surefire with _surefire-junit47_. The provider
_surefire-junit4_ does not use the JUnitCore. Those are interfaces from the
JUnit4.
was (Author: tibor17):
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds_
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds_ has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022866#comment-17022866
]
Tibor Digana edited comment on SUREFIRE-1745 at 1/24/20 10:59 AM:
--
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds_
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds_ has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
was (Author: tibor17):
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds_
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds _has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022866#comment-17022866
]
Tibor Digana commented on SUREFIRE-1745:
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds _
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds _has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022866#comment-17022866
]
Tibor Digana edited comment on SUREFIRE-1745 at 1/24/20 10:58 AM:
--
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds_
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds _has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
was (Author: tibor17):
[~kishoretak]
I think you used another config parameter.
There are two similar names:
_forkedProcessTimeoutInSeconds _
_forkedProcessExitTimeoutInSeconds_
You mentioned both in your comment but i was talking about
*forkedProcessTimeoutInSeconds*.
The second one _forkedProcessExitTimeoutInSeconds _has different behavior - see
doc.
Maybe you can implement this feature o a global timeout. You have to make the
reseach. IMO the _Computer_ or _Request_ should be implemented. Those are
interfaces from the JUnit4.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022853#comment-17022853
]
Tibor Digana commented on SUREFIRE-1745:
It should kill the JVM after certain timeout (forkedProcessTimeoutInSeconds) hs
been reached. And this does not work?
It has to!
It simply breaks the progress of the test suite.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] ajohnstonTE opened a new pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers
ajohnstonTE opened a new pull request #267: [SUREFIRE-1741] JUnit5: Detect failed containers URL: https://github.com/apache/maven-surefire/pull/267 Failed JUnit5 containers will be reported as test failures. This is intended to address [SUREFIRE-1741](https://issues.apache.org/jira/browse/SUREFIRE-1741). Note: I can't comment on the JIRA issue currently, but I will when I get in to work. I just now noticed there's already a PR open that (in my opinion) addresses this issue better and more simply (https://github.com/apache/maven-surefire/pull/257), but since I already wrote it up I'm just gonna open this one anyways. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022832#comment-17022832
]
Kishore Kumar commented on SUREFIRE-1745:
-
It's not shutting down the fork in spite of the shutdown command received as
per the dump.
Also, it will stop the other test(s) of the same class/fork.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022825#comment-17022825
]
Tibor Digana commented on SUREFIRE-1745:
Why it does not help? Unexpected report result?
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022822#comment-17022822
]
Tibor Digana commented on SUREFIRE-1747:
[~atokle]
pls attache the project within a zip filer; otherwise the issue would be too
abstract. It should run tests if you define valid test classes in src/test/java.
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-release] michael-o commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#issuecomment-578034713 Will take another look this afternoon. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
