Hi all,
as already mentioned, I will create a mail thread for each epic that we defined
for the “Support & Care for Apache Maven” initiative
(https://open-elements.com/support-care-maven/).
All information about this specific epic can be found at
https://github.com/OpenElements/maven-support-c
m/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 30 nov. 2022 à 00:44, Kamalpreet Kaur a
écrit :
> Hi Everyone,
>
> I'm currently creating a package from where I would
Hi Everyone,
I'm currently creating a package from where I would want to set JUnit
parallel execution parameters like below :
*classesAndMethods
1
1
false*
I'm planning to use Instrumentation API to inject these parameters. I tried
to find the correct place where I can do so, but fail
Just a heads up, that project has been released just recently with updates
as well.
Thanks
T
On Sat, Nov 5, 2022 at 12:07 PM Mark Raynsford
wrote:
> Hello!
>
> As the subject says: Is there a documented way to write tests for
> plugins under JUnit 5? The only thing I've bee
>
> As the subject says: Is there a documented way to write tests for
> plugins under JUnit 5? The only thing I've been able to find is the
> takari testing project:
>
> https://github.com/takari/takari-plugin-testing-project
>
> There seems to be some preliminary su
On 2022-11-05T12:36:55 +0100
Maarten Mulders wrote:
>
> One solution that I know of is the Integration Testing Framework
> Extension [1] by Karl Heinz Marbaise. The documentation says the project
> is in "an early state but already being useful and can be used for real
> testing".
>
> From my
On 05/11/2022 12:07, Mark Raynsford wrote:
Hello!
As the subject says: Is there a documented way to write tests for
plugins under JUnit 5? The only thing I've been able to find is the
takari testing project:
https://github.com/takari/takari-plugin-testing-project
There seems to be
Hello!
As the subject says: Is there a documented way to write tests for
plugins under JUnit 5? The only thing I've been able to find is the
takari testing project:
https://github.com/takari/takari-plugin-testing-project
There seems to be some preliminary support there, but it's not
ov, wrote:
> Hello everyone.
>
> Maven-plugin maven-plugin-testing-harness
> <https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness>
> still uses JUnit 4
> <https://github.com/apache/maven-plugin-testing/blob/7d6518b0d32d820efa15f7b4d022b852
Hello everyone.
Maven-plugin maven-plugin-testing-harness
<https://github.com/apache/maven-plugin-testing/tree/master/maven-plugin-testing-harness>
still uses JUnit 4
<https://github.com/apache/maven-plugin-testing/blob/7d6518b0d32d820efa15f7b4d022b8524a9b1d1b/maven-plugin-testin
e per fork.
I've submitted the PR against surefire:
https://github.com/apache/maven-surefire/pull/389
Best regards,
Emond
On Sun, Sep 12, 2021 at 9:14 PM Emond Papegaaij
wrote:
> Hi Tibor,
>
> I've reworked the commit to keep the JUnit version at 1.3 and use
> reflecti
mond.papega...@gmail.com> wrote:
> Hi Marc,
>
> Thanks for the links to the documentation. This really helps for my
> Arquillian-Spock extension. It's good to know the LauncherSession was
> introduced to solve this issue.
>
> The problem I see with this new API is that it requir
the documentation. This really helps for my
> Arquillian-Spock extension. It's good to know the LauncherSession was
> introduced to solve this issue.
>
> The problem I see with this new API is that it requires the extension to
> explicitly make use of it. For example, the JUnit 5
, the JUnit 5 Arquillian extension
will need to be adapted to this new API to work correctly with a forkCount
> 1. The same will probably hold for other extensions. The cause of this is
that separate invocations of the launcher do not really share a life cycle.
LauncherSession is able to bi
Hi Tibor,
I've reworked the commit to keep the JUnit version at 1.3 and use
reflection to get the session. Also, I've fixed the issue with the session
used for scanning tests in main thread that remained open. The formatting
is now in line with the checkstyle rules and all tests p
gt;
> T
>
> On Sat, Sep 11, 2021 at 7:52 AM Marc Philipp wrote:
>
>> Hi Emond and Tibor,
>>
>> I’m glad you discovered the new LauncherSession API which was added for
>> this purpose. The JUnit 5.8 GA release will come in the next few days.
>>
>> As yo
Philipp wrote:
> Hi Emond and Tibor,
>
> I’m glad you discovered the new LauncherSession API which was added for
> this purpose. The JUnit 5.8 GA release will come in the next few days.
>
> As you mentrioned, the official documentation does not (yet!) do a good
> job of ex
Hi Emond and Tibor,
I’m glad you discovered the new LauncherSession API which was added for this
purpose. The JUnit 5.8 GA release will come in the next few days.
As you mentrioned, the official documentation does not (yet!) do a good job of
explaining its intended use case:
https://junit.org
Hi Emond,
This section of code is executed for the forkCount > 1
https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L194-L202
The above part runs if the forkCount i
st regards,
Emond
Op vr 10 sep. 2021 23:00 schreef Tibor Digana :
> Hi Emond,
>
> Are you looking for this?
>
> https://github.com/junit-team/junit5/blob/main/documentation/src/test/java/example/UsingTheLauncherDemo.java#L86-L96
>
> On Fri, Sep 10, 2021 at 10:49 PM E
Hi Emond,
Are you looking for this?
https://github.com/junit-team/junit5/blob/main/documentation/src/test/java/example/UsingTheLauncherDemo.java#L86-L96
On Fri, Sep 10, 2021 at 10:49 PM Emond Papegaaij
wrote:
> On Fri, Sep 10, 2021 at 9:15 PM Emond Papegaaij >
> wrote:
>
> &
erSession is the best way to at least provide
>> > some hooks for pre and post fixtures. It shouldn't be too hard to get
>> this
>> > in the current code base with backwards compatibility for JUnit Platform
>> > 1.7 and older. I'll see if I can create a pull reques
> this
> > in the current code base with backwards compatibility for JUnit Platform
> > 1.7 and older. I'll see if I can create a pull request for this somewhere
> > next week.
> >
>
> Before investing too much energy into a PR, please start a discussion or
&g
Sorry for typos, I sent it from my mobile.
T
On Fri, Sep 10, 2021 at 6:18 PM Tibor Digana wrote:
> We have to dig into Junit 5. Surefire is a streamer of classes across the
> forks which is our load balancer. Therefore each class is running
> separately, pre and post fixtures. If th
On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij
wrote:
> [...]
For now, I think the LauncherSession is the best way to at least provide
> some hooks for pre and post fixtures. It shouldn't be too hard to get this
> in the current code base with backwards compatibility for JUnit
On Fri, Sep 10, 2021 at 6:18 PM Tibor Digana wrote:
> We have to dig into Junit 5. Surefire is a streamer of classes across the
> forks which is our load balancer. Therefore each class is running
> separately, pre and post fixtures. If the Junit 5 used Java Streamer
> including
We have to dig into Junit 5. Surefire is a streamer of classes across the
forks which is our load balancer. Therefore each class is running
separately, pre and post fixtures. If the Junit 5 used Java Streamer
including dome kind of control of fixtures then web would have this issue.
Dňa pi 10. 9
em (as can be seen by the demo project). As surefire and failsafe
use the same JUnitPlatformProvider, the problem will also be the same.
What do you think about the solution of using a LauncherSession to bind the
multiple executions together? This will require JUnit Platform 1.8 and
changes in
in quite a long e-mail. For the past
>> few weeks I've been trying to come up with a solution for the issue I
>> filled under SUREFIRE-1935, but I'm getting stuck and starting to feel
>> like
>> the issue cannot be solved with the current JUnit Platform API. To gi
been trying to come up with a solution for the issue I
> filled under SUREFIRE-1935, but I'm getting stuck and starting to feel like
> the issue cannot be solved with the current JUnit Platform API. To give
> some perspective into why this issue is important for us, I first have to
> e
tarting to feel like
the issue cannot be solved with the current JUnit Platform API. To give
some perspective into why this issue is important for us, I first have to
explain a bit about our setup.
We write our tests in the Spock framework and use Arquillian to run the
tests in the application containe
slachiewicz merged pull request #57:
URL: https://github.com/apache/maven-doxia/pull/57
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
dependabot[bot] opened a new pull request #57:
URL: https://github.com/apache/maven-doxia/pull/57
Bumps [junit](https://github.com/junit-team/junit4) from 4.13.1 to 4.13.2.
Release notes
Sourced from https://github.com/junit-team/junit4/releases";>junit's
releases.
27;ve pushed a PR following up the switch to JUnit 5 which includes two
> commits:
> - the use of standard parameterized tests (for speed, I initially reused
> the stuff I wrote for Camel which leads to a smoother migration from junit
> 3/4 parameterized tests, but given there are onl
I've pushed a PR following up the switch to JUnit 5 which includes two
commits:
- the use of standard parameterized tests (for speed, I initially reused
the stuff I wrote for Camel which leads to a smoother migration from junit
3/4 parameterized tests, but given there are only 2 test cl
elharo merged pull request #11:
URL: https://github.com/apache/maven-archiver/pull/11
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 t
elharo opened a new pull request #11:
URL: https://github.com/apache/maven-archiver/pull/11
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 t
asfgit closed pull request #41:
URL: https://github.com/apache/maven-doxia/pull/41
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 t
dependabot[bot] opened a new pull request #41:
URL: https://github.com/apache/maven-doxia/pull/41
Bumps [junit](https://github.com/junit-team/junit4) from 4.13 to 4.13.1.
Release notes
Sourced from https://github.com/junit-team/junit4/releases";>junit's
releases.
elharo merged pull request #2:
URL: https://github.com/apache/maven-reporting-exec/pull/2
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
elharo opened a new pull request #2:
URL: https://github.com/apache/maven-reporting-exec/pull/2
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL abo
guessed.
>
> On Sat, Jun 15, 2019 at 3:07 PM Behrang Saeedzadeh
> wrote:
>
> > Enabled generating Java 9+ projects as well as using JUnit 5.x
> >
> > I have kept the plugin backwards compatible -- if javaCompilerVersion and
> > junitVersion properties are not p
.. but this java 1.7 project and not 1.8 you you have guessed.
On Sat, Jun 15, 2019 at 3:07 PM Behrang Saeedzadeh
wrote:
> Enabled generating Java 9+ projects as well as using JUnit 5.x
>
> I have kept the plugin backwards compatible -- if javaCompilerVersion and
> junitVersion pr
Enabled generating Java 9+ projects as well as using JUnit 5.x
I have kept the plugin backwards compatible -- if javaCompilerVersion and
junitVersion properties are not passed to the plugin it will work as before
and generate a Java 1.8 project with JUnit 4.11.
https://github.com/apache/maven
commit(s) were added to refs/heads/master by this push:
> new de50626 [SUREFIRE-1585] Align JUnit Platform version at runtime
> de50626 is described below
>
> commit de506262225c43e43be4fd64cf25940e5a807aaa
> Author: tibordigana
> AuthorDate: Fri Feb 1 06:03:27 2019 +0
ions... I was sure
yesterday
and earlier today, but had to partly revert changes in our sample projects
to actually
force Surefire to find and execute tests. See [1] for the changes I made. I
fear that
now both versions, 1.2.0 and 1.3.0, do land on the classpath now...
pub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 5 sept. 2018 à 08:23, Dan Tran a écrit :
> > >
> > > > " surefire provider forces 1.2.0" this is not good :-) i thought
> > > sur
. 2018 à 08:23, Dan Tran a écrit :
> >
> > > " surefire provider forces 1.2.0" this is not good :-) i thought
> > surefire
> > > auto detect first one available in classpath
> > >
> > > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
refire
> > auto detect first one available in classpath
> >
> > On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > jupiter ;)
> > >
> > > junit 5 is not jupiter but platform+ engine*s
t; https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 5 sept. 2018 à 08:23, Dan Tran a écrit :
>
> > " surefire provider forces 1.2.0" this is not good :-) i thought
> surefire
> > auto detect first one available in
vided for some junit
> artifacts which can impact the way the classpath is built.
>
>
+1
Tibor got a good point noticing that we use scope provided for some junit
artifacts which can impact the way the classpath is built.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibuca
refire, JUnit 5 sample
projects, Spring Boot, et al.
... therefore it ignores the project overrides without my patch.
Which is an improvement! And Surefire needs such a logic. I did something
similar here:
https://github.com/sormuras/junit-platform-maven-plugin/blob/05b7e3ae521ccb7f71d00ccd532523a99a
nfirmation of that
> as it may impact Spring Boot (amongst other things)
>
> Thanks,
> S.
>
>
> On Wed, Sep 5, 2018 at 10:13 AM Romain Manni-Bucau
> wrote:
>
> > @Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
> > and change the versio
.
On Wed, Sep 5, 2018 at 10:13 AM Romain Manni-Bucau
wrote:
> @Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
> and change the version in the junit pom (
> https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml),
> it will fail then
@Stephane: you can clone https://github.com/apache/meecrowave/tree/trunk
and change the version in the junit pom (
https://github.com/apache/meecrowave/blob/trunk/meecrowave-junit/pom.xml),
it will fail then
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
t to use 5.3.0 and I don't see any
> problem.
>
>
That's my point: I'm not saying the current implementation is perfect and
that
can't be improved, but there are successful migrated projects that work with
Surefire 2.22.0 and JUnit 5.3 "flawlessly".
Romain is point
t 10:46 PM Romain Manni-Bucau
wrote:
> Hi guys,
>
> Jira seems down so sending a mail.
>
> I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I realized
> the way surefire provider was developped for JUnit 5 was forcing the
> junit-platform-engine even adding it ma
, 2018 at 11:06 PM Romain Manni-Bucau
> wrote:
>
> > jupiter ;)
> >
> > junit 5 is not jupiter but platform+ engine*s* so it must detect the full
> > stack and not just the default. A first step can be to detect
> > platform+jupiter+engine but I guess we will get spock, cucum
" surefire provider forces 1.2.0" this is not good :-) i thought surefire
auto detect first one available in classpath
On Tue, Sep 4, 2018 at 11:06 PM Romain Manni-Bucau
wrote:
> jupiter ;)
>
> junit 5 is not jupiter but platform+ engine*s* so it must detect the full
>
jupiter ;)
junit 5 is not jupiter but platform+ engine*s* so it must detect the full
stack and not just the default. A first step can be to detect
platform+jupiter+engine but I guess we will get spock, cucumber etc engine
quickly so being generic can be worth it. In my case I have vintage-engine
Odd, I am under impression surefire auto detect junit-jupiter-engine at
runtime
am I missing something?
-D
On Tue, Sep 4, 2018 at 10:08 PM Romain Manni-Bucau
wrote:
> It does _NOT_ work and as mentionned you can test on meecrowave trying to
> upgrade the version in junit module.
&
It does _NOT_ work and as mentionned you can test on meecrowave trying to
upgrade the version in junit module.
The test classpath build ignores project and plugin dependencies. It faked
working until 5.3.0-RC1 cause no breakage was visible.
When testing, dont forget to use jupiter, vintage
Ok perso I don't mind (it just need to be documented)
But the issue is: users are used to simply upgrade their junit dependency.
On Wed, 5 Sep 2018 at 07:37, Christian Stein wrote:
> No, it works with Surefire 2.22.0 and JUnit 5.3.
>
> Just add (or move) the test-runtime depen
No, it works with Surefire 2.22.0 and JUnit 5.3.
Just add (or move) the test-runtime dependencies to the Surefire plugin
element:
maven-surefire-plugin
2.22.0
org.junit.jupiter
junit
Hi
very embarrassing issue which probably worth a quick release!
Can you create a jira?
As junit 5.3.0 has just been released, I might be happy to cut 2.22.1 very
quickly with only this fix.
others wdyt?
On Wed, 5 Sep 2018 at 06:46, Romain Manni-Bucau
wrote:
> Hi guys,
>
> Jira seem
Hi guys,
Jira seems down so sending a mail.
I wanted to upgrade Meecrowave to JUnit 5.3 since it is out but I realized
the way surefire provider was developped for JUnit 5 was forcing the
junit-platform-engine even adding it manually in the test dependencies or
plugin dependencies.
Side note: I
Hi all,
I wrote my first Maven Plugin: "junit-platform-maven-plugin" [1].
It is a convenient wrapper starting the JUnit Platform Console Launcher [2].
I'd appreciate a quick review if I followed the common and
recommended standards for writing Maven Plugins. I opened
an issu
Hi,
I would lke to use the categories facility with JUnit 4.12 in a reactor
project, I am finding some issue, but they seem to me so basic that maybe
it is only a lack of documentation or that we can provide some minor fix in
order to make life easier:
1) In a reactor a would like to run mvn test
GitHub user luankevinferreira opened a pull request:
https://github.com/apache/maven-archetype/pull/18
Update JUnit dependency version.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/luankevinferreira/maven-archetype patch-1
my illness, thx.
> >> I am finishing branch SUREFIRE-1262_2. Just to add few more tests and
> then
> >> I will cut a release. I want to add a fix for SUREFIRE-1374 which would
> be
> >> fast to do.
> >> Then I am ready for you and JUnit5.
> >>
&g
; fast to do.
>> Then I am ready for you and JUnit5.
>>
>> I have questions regarding our JUnit 5 Surefire Provider implemented in
>> Surefire.
>>
>> Is it implemented exactly in the same like the origin by junit5 team?
>> I am asking because I saw the imple
want to add a fix for SUREFIRE-1374 which would be
> fast to do.
> Then I am ready for you and JUnit5.
>
> I have questions regarding our JUnit 5 Surefire Provider implemented in
> Surefire.
>
> Is it implemented exactly in the same like the origin by junit5 team?
> I am as
Hi Benedikt,
I am fine now after my illness, thx.
I am finishing branch SUREFIRE-1262_2. Just to add few more tests and then
I will cut a release. I want to add a fix for SUREFIRE-1374 which would be
fast to do.
Then I am ready for you and JUnit5.
I have questions regarding our JUnit 5 Surefire
on
> 2.22.0. Altough Surifire is compiled with javac -source 1.6 -target 1.6, and
> JUnit 5/Java 1.8 provider is standalone jar file which does not force the
> plugin itself to load Java 8 classes from the provider, we can freely work on
> JUnit 5 provider after the version 2.21.0.Ji
Hi Benedikt,
Would you agree with this plan.
Since we try to release version 2.21.0 with Jigsaw modularity which is Java
9 related feature, we can make the same compromise with JUnit5 in next
version 2.22.0. Altough Surifire is compiled with javac -source 1.6 -target
1.6, and JUnit 5/Java 1.8
gt; > Can you share some stacktrace? This will give a first hint without having
> > to build jUDDI
>
> This is the wrong mailing list...Users list was the subject about jUDDI
> ;-)..
>
> Not related to Surefire and JUnit 5 ...
>
> Kind regards
> Karl Heinz Marbaise
&g
;-)..
Not related to Surefire and JUnit 5 ...
Kind regards
Karl Heinz Marbaise
Cheers
Enrico
Il sab 30 set 2017, 10:34 Benedikt Ritter ha scritto:
Hello,
for over a year now I’m trying to help getting JUnit 5 support into Maven
Surefire. This has been hard since Tibor seems to be the only
p getting JUnit 5 support into Maven
> Surefire. This has been hard since Tibor seems to be the only one
> maintaining Maven Surefire and he had to come with other things.
>
> For this reason I’d like to ask other Maven maintainers to help with the
> JUnit 5 support. I’m happy
Hello,
for over a year now I’m trying to help getting JUnit 5 support into Maven
Surefire. This has been hard since Tibor seems to be the only one maintaining
Maven Surefire and he had to come with other things.
For this reason I’d like to ask other Maven maintainers to help with the JUnit
5
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/162
@britter
Done. I added enforcer configuration. I hope it will be fine.
Let me know if you have something to do for me.
Sometimes I am without internet connection for several days o
Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/162
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
I will have a look.
On Mon, Aug 28, 2017 at 8:49 PM, britter wrote:
> Github user britter commented on the issue:
>
> https://github.com/apache/maven-surefire/pull/162
>
> @Tibor17 any news on this?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
>
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/162
@Tibor17 any news on this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled a
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/162
Sorry my bad, yes master has enforcer with JDK8 (due to javadoc checks
within compile time) however maven.compoler.source/target is 1.6.
I will have a look in to junit5 branch.
---
If yo
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/162
@Tibor17 for the JUnit Plattform Provider we even need JDK 8! Can you merge
Master to junit5 Branch so we have the enforcer fixes? Than I can rebase this
PR.
Thank you!
---
If
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/162
@britter
Actually the master is on JDK6 and the branch junit5 could be on JDK5 that
time we created it.
Maybe you should fix the enforcer configuration to similar to the one in
maste
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/162
@Tibor17 when I run `mvn compile` I get:
```
Restricted to JDK 1.5 yet
org.apache.maven.surefire:surefire-api:jar:2.19.2-SNAPSHOT:compile contains
org/apache/maven/plugin/surefir
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/153
See #162
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
GitHub user britter opened a pull request:
https://github.com/apache/maven-surefire/pull/162
SUREFIRE-1384: ProviderInfo for JUnit Plattform (WIP)
Followup for #153
This is Work in Progress! First take on a JUnitPlattform ProviderInfo, to
enable automatic provider lookup
Github user britter closed the pull request at:
https://github.com/apache/maven-surefire/pull/153
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the featur
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/153
Opening a new PR against junit5 branch!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feat
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@Tibor17 I'll have a look at the state of the junit5 branch next week.
Thank you!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as we
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
#155 and #154 are done. Pls let me know if I should continue with #153.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/155
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@Tibor17 I'd say this order:
- #155: revert stuff from rc1 branch
- #154: Add the stuff to junit5 branch
#153 I have to rework, since we have to target it at junit5 branch
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
In what order should this PR and
https://github.com/apache/maven-surefire/pull/153 be pushed?
Is https://github.com/apache/maven-surefire/pull/154 independent?
---
If your
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
We have finished feature SUREFIRE 1302 and I am going get back to JUnit5.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/160
@MatousJobanek
It should be sanity check and Mojo should fail if `threadCount` is <= 0 &&
isApplicable.
IsApplicable is TRUE if `forkMode` is "pertest" OR `parallel` is any of
("clas
Github user MatousJobanek commented on the issue:
https://github.com/apache/maven-surefire/pull/160
Sorry, I didn't notice that the parameter is used also in other cases.
I changed the commit to set the `threadCount` only when it is a positive
value also in case of JUnit - i
1 - 100 of 500 matches
Mail list logo
