Hi,
I am updating my old Maven Enforcer custom rules (from 2016) to use the
new API.
When using the old API, I also used the
/org.apache.maven.enforcer:enforcer-rules::*test-jar*/ for testing my rules.
The new API documents make no mention of the test jar.
The test-jar has not been
Hi,
Try -Dinvoker.test=analyze
On Mon, 11 Nov 2024 at 21:16, Elliotte Rusty Harold wrote:
>
> Anyone happen to recall the incantation to run a single integration
> test? E.g. something like
>
> mvn -P run-its verify -Dtest=analyze/pom.xml
>
>
> --
> Elliotte Rusty
Anyone happen to recall the incantation to run a single integration
test? E.g. something like
mvn -P run-its verify -Dtest=analyze/pom.xml
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr
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
Le 2024-05-21 à 11 h 18, Guillaume Nodet a écrit :
https://github.com/Geomatys/maven/commit/5165ca60a1b44cd2a376cd1bfe48f558a2cbd54f
looks interesting, as the interface was introduced in 4.x branch, so no
need to keep it as it's not used anymore. Feel free to create a proper PR.
Thanks, done.
sts are the most up-to-date code for Maven 4,
>>> would it be possible to update them to "4.0.0-beta-2"? I tried to do
>>> that on my side, but got some difficulties. First, it seems that the
>>> following changes must be applied on Maven core for making possible t
Maven core for making possible to
>> compile the plugins:
>>
>> *
>> https://github.com/Geomatys/maven/commit/5165ca60a1b44cd2a376cd1bfe48f558a2cbd54f
>>
>> I have not created a pull request for the above because I'm not sure if
>> I understood the iss
Hello Tamas
Thanks for the explanation. Then I will pause the Maven compiler plugin
work for now and resume after the new master branches are ready (I need
to focus on 2 meetings in June anyway). Just for avoiding confusion,
would it be possible to delete the current "mvn4" branches?
Side no
ve because I'm not sure if
> I understood the issue correctly. Next, after changing the dependencies
> to "4.0.0-beta-3-SNAPSHOT", the build of "maven-plugin-testing-harness"
> has the following test failure:
>
> java.l
a pull request for the above because I'm not sure if
I understood the issue correctly. Next, after changing the dependencies
to "4.0.0-beta-3-SNAPSHOT", the build of "maven-plugin-testing-harness"
has the following test failure:
java.lang.IllegalArgumentExce
maven-invoker/usage.html
>
> tison 于2024年1月25日周四 11:09写道：
> >
> > Hi,
> >
> > I'm writing a Mojo with an Extension extending
> > AbstractMavenLifecycleParticipant.
> >
> > Now, I'd like to write some tests on the extension logic. Although
> >
LifecycleParticipant.
>
> Now, I'd like to write some tests on the extension logic. Although
> Maven provides docs about writing tests over Mojos[1], it doesn't tell
> how to test if an extension [2] is properly loaded and executed.
>
> Are there some examples of such
Hi,
I'm writing a Mojo with an Extension extending
AbstractMavenLifecycleParticipant.
Now, I'd like to write some tests on the extension logic. Although
Maven provides docs about writing tests over Mojos[1], it doesn't tell
how to test if an extension [2] is properly loaded and
On Wed, Mar 22, 2023 at 12:36 PM Laird Nelson wrote:
> I understand patching the "main" module with target/classes.
>
(Actually, I take it back. Given that --module-path
/path/to/myproject/target/classes is also present, I don't understand why
target/classes would be patched in either.)
L
>
I've noticed that the Maven compiler plugin's test-compile goal (version
3.11.0) adds --patch-module
my.module=/path/to/myproject/target/classes:/path/to/myproject/src/test/java
to the javac invocation when I have a src/main/java/module-info.java.
I understand patching the "ma
hink you need to run the package phase as hinted by the error.
> >
>
>
> mvn test
>
> also
>
> mvn compile; mvn test
> mvn clean test
> mvn package; mvn test
>
> All end with the same failure. This seems to be a regression in 4.0. I
> don't see this o
On Sat, Feb 25, 2023 at 11:46 AM Guillaume Nodet wrote:
>
> Which goal are you running ?
> I think you need to run the package phase as hinted by the error.
>
mvn test
also
mvn compile; mvn test
mvn clean test
mvn package; mvn test
All end with the same failure. This seems to be
Which goal are you running ?
I think you need to run the package phase as hinted by the error.
Le sam. 25 févr. 2023 à 07:58, Elliotte Rusty Harold a
écrit :
> FYI, maven core tests fail for me (Java 1.8. Maven 3.8.7) when
> building at head like so. I'm not sure what to do about this:
>
> [INFO
FYI, maven core tests fail for me (Java 1.8. Maven 3.8.7) when
building at head like so. I'm not sure what to do about this:
[INFO] Unpacking
/Users/elharo/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.0/plexus-utils-3.5.0.jar
to /Users/elharo/maven/plexus-utils/target/classes with includes
Hi Herve,
I saw your fix but I was wondering if just adding those two lines to the
bootstrap.txt:
+org.apache.maven.plugins:maven-dependency-plugin:3.1.1
+org.apache.maven.plugins:maven-dependency-plugin:3.3.0
wouldn't be a simpler fix. The test itself seems fine, just the deps are
missing
t; Le lundi 22 août 2022, 06:50:40 CEST Henning Schmiedehausen a écrit :
> >> Folks,
> >>
> >> I am somewhat struggling to make integration tests pass for PRs. And it
> >> seems that I am not alone. Looking at
> >> https://github.com/apache/maven/commits/mas
0 CEST Henning Schmiedehausen a écrit :
Folks,
I am somewhat struggling to make integration tests pass for PRs. And it
seems that I am not alone. Looking at
https://github.com/apache/maven/commits/master, none of the merged commits
on master has successfully passed the test suite. It seems to have
t;
> > I am somewhat struggling to make integration tests pass for PRs. And it
> > seems that I am not alone. Looking at
> > https://github.com/apache/maven/commits/master, none of the merged commits
> > on master has successfully passed the test suite. It seems to have started
&
pass for PRs. And it
> seems that I am not alone. Looking at
> https://github.com/apache/maven/commits/master, none of the merged commits
> on master has successfully passed the test suite. It seems to have started
> with the "[MNG-7353] ..." commit here:
> https://github
Folks,
I am somewhat struggling to make integration tests pass for PRs. And it
seems that I am not alone. Looking at
https://github.com/apache/maven/commits/master, none of the merged commits
on master has successfully passed the test suite. It seems to have started
with the "[MNG
3.0 a warning is reported:
[WARNING] Non-test scoped test only dependencies found:
[WARNING]test:lib1:jar:0.1-SNAPSHOT:compile
However, this appears to be a true positive. If in service/pom.xml when I change
test
lib1
to either
t; (dependency-shaded) and then uses that shaded dependency to build a shaded
> service:
>
> service-shaded -> dependency-shaded (which contains dependency, lib1 and
> lib2)
>
> To establish a baseline with 3.1.2, run "mvn -Pold-dep clean install" (Use
> Java 11 for
pendency-shaded (which contains dependency, lib1 and
lib2)
To establish a baseline with 3.1.2, run "mvn -Pold-dep clean install" (Use
Java 11 for this).
The code should build successfully, all unit tests pass. No errors are
thrown.
Test the services:
java -jar service-shaded/target/servic
g this
> conversation here ]
>
> The latest releases of the maven dependency plugin (3.2.0, 3.3.0)
> introduced some changes in the way test dependencies are handled and
> potentially flagged. Especially the "Non-test scoped test only dependencies
> found" warning/error has
Hi,
[I discussed this on slack with @sjaranowski, he suggested to bring this
conversation here ]
The latest releases of the maven dependency plugin (3.2.0, 3.3.0)
introduced some changes in the way test dependencies are handled and
potentially flagged. Especially the "Non-test scoped test
Hi,
We have open issue MDEP-791 [1] for maven dependency plugin
There are also connected issues for Maven core MNG-6058 [2] and
probably others.
Do we have any idea how this should be resolved ... fix in m-dependency-p
or in Maven core?
I'm afraid that even if we fix in core ... we should have s
gt;
>>
>> Hi
>>
>> My surefire 3.0.0-M4 classpath contains both junit4 and junit5 providers,
>> and surefire beautifully run both junit4 and junit test classes
>>
>> with 3.0-M6-SNAPSHOT, surefire ignores all junit 5 test class
>>
>> [INFO
>From the console log, looks like junit4 provider got picked up first and
lock-in?
-D
On Mon, Mar 7, 2022 at 9:56 PM Dan Tran wrote:
>
> Hi
>
> My surefire 3.0.0-M4 classpath contains both junit4 and junit5 providers,
> and surefire beautifully run both junit4 and junit tes
Hi
My surefire classpath contains both junit4 and junit5 providers, and
surefire beautifully run both junit4 and junit test classes
with 3.0-M6-SNAPSHOT, surefire ignores all junit 5 test class
[INFO] --- maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test (default-test) @
xxxt ---
[INFO] Surefire
slawekjaranowski commented on pull request #16:
URL:
https://github.com/apache/maven-gh-actions-shared/pull/16#issuecomment-952578883
not needed .. yet .. I must do more tests
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub
slawekjaranowski closed pull request #16:
URL: https://github.com/apache/maven-gh-actions-shared/pull/16
--
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.
To unsubscribe, e
slawekjaranowski opened a new pull request #16:
URL: https://github.com/apache/maven-gh-actions-shared/pull/16
Test has static reference for branch,
so should be executed on corresponding branch
--
This is an automated message from the Apache Git Service.
To respond to the message
>> I would not want it to be log4j-core-tests-3.0.0-SNAPSHOT.jar as that
would not be understood to be a test jar.
If this artifact is intended for log4j only, consider skipping install/deploy.
But then I wonder why there's a need for a module descriptor.
If it is intended to be used
Some of the code is shared on the test side just like you shared code on
the main side, there is nothing unusual abour that. For example test
infrastructure, utilities, JUnit rules, and do on.
Gary
On Wed, Jun 23, 2021, 02:54 Jochen Wiedmann
wrote:
> On Tue, Jun 22, 2021 at 9:32 PM G
On Tue, Jun 22, 2021 at 9:32 PM Gary Gregory wrote:
>
> It feels to me like JPMS just plainly breaks the informal industry standard
> of the Maven project layout we have all been using for a million years.
I don't think so. Reusing test classes downstream sounds to me highly un
> On Jun 22, 2021, at 2:29 PM, Andres Almiray wrote:
>
> Ralph,
>
> Once you move test code to their own Maven module they become a top level
> module, that is, they have a life of their own as any other top level module.
>
> In contrast -tests jars are not t
Ralph,
Once you move test code to their own Maven module they become a top level
module, that is, they have a life of their own as any other top level module.
In contrast -tests jars are not top level, but a “variant” (that’s why they
have a classifier) of their owning top level module.
Test
> On Jun 22, 2021, at 11:16 AM, Robert Scholte wrote:
>
> If I understand correctly you want both log4j-core main classes and test
> classes be distributed as modularized jars.
> To me with JPMS you should move the modularized test-classes to a separate
> Maven module
That's just broken, I can have any number of package private classes (or
methods) that perform lower level or non-customer appropriate tasks but
that are large enough or complex enough to merrit unit testing on their own.
Only testing public APIs is saying that blackboxing is the only way to
Ralph,
Apologies. I did not link to Jipsy as a suggestion to be used as a dependency
but rather as an example of how the ModiTect plugin may be applied to a project
that produces and tests an APT.
I believe Jipsy has a 2nd Maven module that produces a “test” jar without it
being an actual
Andres,
I looked at moditect when I first started doing the work. I’m afraid I am not
understanding how
it could help solve the problem with the test jar and unit tests. Could you
please explain that?
I am also not sure I understand how Jipsy will help. Log4j generates the file
in META-INF
Gary, the test jar doesn’t perform tests. It provides test utility classes like
LoggerContextRule.
> On Jun 22, 2021, at 12:31 PM, Gary Gregory wrote:
>
> It feels to me like JPMS just plainly breaks the informal industry standard
> of the Maven project layout we have all been
> On Jun 22, 2021, at 1:19 PM, Elliotte Rusty Harold wrote:
>
> On Tue, Jun 22, 2021 at 7:32 PM Gary Gregory wrote:
>
>> In addition, how is one supposed to test package private code if a test jar
>> tests a main jar where all packages are now different?
>
> On Jun 22, 2021, at 12:01 PM, Benjamin Marwell wrote:
>
>> So now you would have a maven module with only the main source and no tests,
>> and a second module
>> where the “main” source is actually the test classes
>> and the unit tests test the code in a di
On Tue, Jun 22, 2021 at 7:32 PM Gary Gregory wrote:
> In addition, how is one supposed to test package private code if a test jar
> tests a main jar where all packages are now different?
Some projects adhere to strictly testing through the public API only.
It definitely makes tests more
It feels to me like JPMS just plainly breaks the informal industry standard
of the Maven project layout we have all been using for a million years.
In addition, how is one supposed to test package private code if a test jar
tests a main jar where all packages are now different? This seems like a
> So now you would have a maven module with only the main source and no tests,
> and a second module
> where the “main” source is actually the test classes
> and the unit tests test the code in a different Maven
> module with a module info that opens the module-info of the
Yes, you understand correctly. And yes, the test classes could be moved to a
separate maven module, but
then the unit tests would also have to move as well as they are dependent on
those test classes. Of course,
the test classes are dependent on the main source. As an example, log4j-core
has
If I understand correctly you want both log4j-core main classes and test
classes be distributed as modularized jars.
To me with JPMS you should move the modularized test-classes to a separate
Maven module as a first citizen artifact.
That should make it a lot easier.
It should also make the
e/view_bug.do?bug_id=JDK-8265826 <
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826>.
>This bug has been fixed in Java 17 but Log4j uses Java 11 to build.
> 2. Log4j-plugins builds an annotation processor, packages it with the
> annotations
>and classes nec
nd run plugins, creates and test jar and
runs unit tests.
3. It is not possible to compile an annotation processor with a
module-info.java present.
The compile will fail because it can’t find the annotation processor
“service” when
compiling module-info.java.
4. It is very difficult to comp
Java 11 to build.
2. Log4j-plugins builds an annotation processor, packages it with the
annotations
and classes necessary to build and run plugins, creates and test jar and
runs unit tests.
3. It is not possible to compile an annotation processor with a
module-info.java present.
The
asfgit closed pull request #37:
URL: https://github.com/apache/maven-site-plugin/pull/37
--
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, p
elharo opened a new pull request #37:
URL: https://github.com/apache/maven-site-plugin/pull/37
Mostly I want to see if the CI works or not
This is an automated message from the Apache Git Service.
To respond to the message, p
Oops sent this to the wrong emailSent from my iPhoneBegin forwarded message:From: Claudio Corsi Date: December 15, 2020 at 20:38:30 ESTTo: dev-h...@maven.apache.orgSubject: [maven-compiler-plugin] Issue with compiling test source using modules using a multi-version maven project.Hi All,I am
rfscholte commented on pull request #13:
URL: https://github.com/apache/maven-archiver/pull/13#issuecomment-728265093
ok, just wanted to make sure change is done for the right reason.
This is an automated message from the Apa
elharo commented on pull request #13:
URL: https://github.com/apache/maven-archiver/pull/13#issuecomment-728255605
I don't think it is. That was an incorrect diagnosis of the test failure.
The modification data equality failures were not simply the result of
truncating milliseconds
rfscholte commented on pull request #13:
URL: https://github.com/apache/maven-archiver/pull/13#issuecomment-728251174
Wait a minute, isn't this fixed with
https://github.com/codehaus-plexus/plexus-archiver/commit/e55f320f190bc5fe2b1029c4fd8bb3e294a299bc
?
elharo merged pull request #13:
URL: https://github.com/apache/maven-archiver/pull/13
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 #13:
URL: https://github.com/apache/maven-archiver/pull/13
Consequently failing flakily. Last modified time is platform dependent and
not a simpler property of an object
@michael-o
---
elharo merged pull request #12:
URL: https://github.com/apache/maven-archiver/pull/12
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 commented on a change in pull request #12:
URL: https://github.com/apache/maven-archiver/pull/12#discussion_r524283416
##
File path: src/test/java/org/apache/maven/archiver/MavenArchiverTest.java
##
@@ -276,13 +273,8 @@ public void testRecreation
elharo opened a new pull request #12:
URL: https://github.com/apache/maven-archiver/pull/12
@michael-o
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
Hey all,
Since we enabled GitHub Actions on Maven it fully succeeded only once on
the Apache GitHub group [1].
After a quick crosscheck I found out that we seem to have a flaky
test: MavenITmng5175WagonHttpTest#testmng5175_ReadTimeOutFromSettings.
It's flaky since it succeeded once yesterd
slachiewicz merged pull request #1:
URL: https://github.com/apache/maven-project-utils/pull/1
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
elharo opened a new pull request #1:
URL: https://github.com/apache/maven-project-utils/pull/1
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL abov
Am 2020-07-01 um 11:25 schrieb Maarten Mulders:
Hi all,
Ever since I started contributing on Maven, I noticed that there's one
integration test that fails on my machine (a Macbook). The test is
located in the MavenITmng6386BaseUriPropertyTest class, more
specificall
Hi all,
>>>>
>>>> Ever since I started contributing on Maven, I noticed that there's one
>>>> integration test that fails on my machine (a Macbook). The test is
>>>> located in the MavenITmng6386BaseUriPropertyTest class, more
>>>> spe
um 11:25 schrieb Maarten Mulders:
> >> Hi all,
> >>
> >> Ever since I started contributing on Maven, I noticed that there's one
> >> integration test that fails on my machine (a Macbook). The test is
> >> located in the MavenITm
On 01/07/2020 15:21, Michael Osipov wrote:
> Am 2020-07-01 um 11:25 schrieb Maarten Mulders:
>> Hi all,
>>
>> Ever since I started contributing on Maven, I noticed that there's one
>> integration test that fails on my machine (a Macbook
Am 2020-07-01 um 11:25 schrieb Maarten Mulders:
Hi all,
Ever since I started contributing on Maven, I noticed that there's one
integration test that fails on my machine (a Macbook). The test is
located in the MavenITmng6386BaseUriPropertyTest class, more
specificall
Hi,
Thx for reporting - our GitHub CI integration test run on macos [1] also
failed. Let's try to fix it.
Sylwester
[1] https://github.com/apache/maven/actions/runs/153922419
śr., 1 lip 2020, 11:25 użytkownik Maarten Mulders
napisał:
> Hi all,
>
> Ever since I started contributi
Hi all,
Ever since I started contributing on Maven, I noticed that there's one
integration test that fails on my machine (a Macbook). The test is
located in the MavenITmng6386BaseUriPropertyTest class, more
specifically the testitMNG6386UnicodeChars method.
I always thought it would be &quo
efault/
I havent used plexus since sisu and google-guice were released
does this answer your question?
m.
From: Benson Margulies
Sent: Friday, May 8, 2020 5:16 PM
To: Maven Developers List
Cc: volf...@google.com
Subject: Running mojo unit test in the debugger
From: Benson Margulies
Sent: Friday, May 8, 2020 5:16 PM
To: Maven Developers List
Cc: volf...@google.com
Subject: Running mojo unit test in the debugger
I am trying to recall how to debug a Junit test that uses
AbstractMojoTestCase. Simply asking an IDE to
perso I'm using -Dmaven.surefire.debug and attach a debugger
I only trust Maven build (not IDE build :) )
On Sat, 9 May 2020 at 07:17, Benson Margulies wrote:
> I am trying to recall how to debug a Junit test that uses
> AbstractMojoTestCase. Simply asking an IDE to debug the test
I am trying to recall how to debug a Junit test that uses
AbstractMojoTestCase. Simply asking an IDE to debug the test fails with
plexus container errors. I cannot recall if these can be debugged as
ordinary unit tests somehow, or whether we need to set remote debugging
options to the surefire
t; Le mercredi 22 janvier 2020, 18:12:30 CET Elliotte Rusty Harold a écrit
> :
> > > > > Ping. Any progress on getting Doxia migrated into Github?
> > > > >
> > > > > On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
> > > > >
>
nvier 2020, 18:12:30 CET Elliotte Rusty Harold a écrit
:
> > > > Ping. Any progress on getting Doxia migrated into Github?
> > > >
> > > > On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
> > > >
> > > > wrote:
> > > > &
hub?
> > >
> > > On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
> > >
> > > wrote:
> > > > Anyone working on Doxia these days? If so, your review of
> > > > https://github.com/apache/maven-doxia-tools/pull/3 would be
> > &g
:
> > > Anyone working on Doxia these days? If so, your review of
> > > https://github.com/apache/maven-doxia-tools/pull/3 would be
> > > appreciated. This PR effectively disables a flaky autogenerated test.
> > >
> > > This was the best I could come up w
ld be
> > appreciated. This PR effectively disables a flaky autogenerated test.
> >
> > This was the best I could come up with on short notice to unblock some
> > other bugs in Doxia. However if anyone can figure out how to fix the
> > autogenerated test ins
bles a flaky autogenerated test.
>
> This was the best I could come up with on short notice to unblock some
> other bugs in Doxia. However if anyone can figure out how to fix the
> autogenerated test instead that would be even better. Details at
>
> https://issues.apache
ok at this, we need to know the status of it.
> > >
> > > thanks,
> > > Robert
> > >
> > > On 23-12-2019 23:38:43, Elliotte Rusty Harold
> > > wrote:
> > > Anyone working on Doxia these days? If so, your review of
> > > http
> > Before having a look at this, we need to know the status of it.
> >
> > thanks,
> > Robert
> >
> > On 23-12-2019 23:38:43, Elliotte Rusty Harold wrote:
> > Anyone working on Doxia these days? If so, your review of
> > https://github.com/apache
ng on Doxia these days? If so, your review of
> https://github.com/apache/maven-doxia-tools/pull/3 would be
> appreciated. This PR effectively disables a flaky autogenerated test.
>
> This was the best I could come up with on short notice to unblock some
> other bugs in Doxia. H
te:
> Anyone working on Doxia these days? If so, your review of
> https://github.com/apache/maven-doxia-tools/pull/3 would be
> appreciated. This PR effectively disables a flaky autogenerated test.
>
> This was the best I could come up with on short notice to unblock some
> other bu
Elliotte Rusty Harold wrote:
> Anyone working on Doxia these days? If so, your review of
> https://github.com/apache/maven-doxia-tools/pull/3 would be
> appreciated. This PR effectively disables a flaky autogenerated test.
>
> This was the best I could come up with on short notic
-12-2019 23:38:43, Elliotte Rusty Harold wrote:
Anyone working on Doxia these days? If so, your review of
https://github.com/apache/maven-doxia-tools/pull/3 would be
appreciated. This PR effectively disables a flaky autogenerated test.
This was the best I could come up with on short notice to
Anyone working on Doxia these days? If so, your review of
https://github.com/apache/maven-doxia-tools/pull/3 would be
appreciated. This PR effectively disables a flaky autogenerated test.
This was the best I could come up with on short notice to unblock some
other bugs in Doxia. However if anyone
27;, but yes might be
> seamed as more user friendly.
>
> For some projects I've both surefire unit tests and failsafe
> integration tests in 'src/test/java', but IntelliJ just executes both
> and so often the integration tests fail as I've not setup the pre
> reqs.
&
I've both surefire unit tests and failsafe
integration tests in 'src/test/java', but IntelliJ just executes both
and so often the integration tests fail as I've not setup the pre
reqs.
In large code bases it good to have tests within files names including
the word 'Test&#x
Hi everyone,
Today a colleague asked me why "FooWhateverBla" test was not executed with
maven whereas it works well in Intellij.
Indeed I explained him Surefire does its own scanning and the hardcoded
defaults but I actually wonder why we still do that and if it is not just
something
> dead
> > and move these features into Junit5.
> >
>
> My request is unrelated to JUnit 5 or how the test report is currently
> created.
>
>
> >
> > The RunListener could be always added. So it exists in JUnit4 and TestNG
> > provider for the purposes like c
like Junit5 wants to remove the Surefire report out been dead
> and move these features into Junit5.
>
My request is unrelated to JUnit 5 or how the test report is currently
created.
>
> The RunListener could be always added. So it exists in JUnit4 and TestNG
> provider for the pu
1 - 100 of 4001 matches
Mail list logo
