Sat, 30 Mar 2024, /Debraj Manna/:
As suggested by Stanimir if I remove the test-jar type and also the
includes like below then mvn package --projects=:agent -T 2 --also-make
works
[...]
But if I add back the below inclusion it again starts throwing the
NoClassDefFoundError
[...]
At least
As suggested by Stanimir if I remove the test-jar type and also the
includes like below then mvn package --projects=:agent -T 2 --also-make
works
org.apache.maven.plugins
maven-jar-plugin
3.3.0
test-jar
But if I
Thu, 28 Mar 2024, /Debraj Manna/:
Ok I can try that but I can see the type test-jar from the below
documentation
https://maven.apache.org/guides/mini/guide-attached-tests.html
I hadn't been aware of it. It could be specific to the ear-plugin:
* https://issues.apache.org/jira/browse
Ok I can try that but I can see the type test-jar from the below
documentation
https://maven.apache.org/guides/mini/guide-attached-tests.html
On Thu, Mar 28, 2024 at 3:11 PM Stanimir Stamenkov
wrote:
> Thu, 28 Mar 2024, /Debraj Manna/:
>
> > But I am still facing issues in th
Thu, 28 Mar 2024, /Debraj Manna/:
But I am still facing issues in the below case.
[...]
com.spotnana
synapse
0.0.1-SNAPSHOT
tests
test-jar
This doesn't seem right. I'm not aware of test-jar –
should be just jar (or just omit it as it is implied).
test
N
Gary
Somehow your message went into my spam folder.
The idea was in synapse there were certain utility classes which other
modules should only use while writing integration tests with synapse. The
test classes are not expected to be used in non-test code by other modules.
synapse also contains
As suggested the below config is working fine
org.apache.maven.plugins
maven-jar-plugin
3.3.0
test-jar
3.3.0
common/**
test-jar
I am observing that the test-jar is getting created as expected containing
only the code from test/java
I think the "simple" solution is to use 2 maven modules, then you don't
need to do anything special. The layout does not make sense to me so I must
be missing something. If the common code is needed for both main and test,
then it should be in main. You can put that common code in
I have a Maven module named synapse.
main
java
package1
A.java
test
java
common
C.java
package1
ATest.java
Can someone let me know if in Maven I can create a non-executable jar
containing all non-test code (main/) and another test-jar containing only
the code
Nevermind. I had the package name wrong. I used the package name from my
main classes in addition to the test class.
Sorry for the confusion.
Thank you,
Neil
--
Neil Aggarwal, 972-834-1565, http://propfinancing.com
We offer 30 year loans on single family houses!
*From:* Neil
I have a test class krazydad.slitherlink.SolverTest
It has a method public void testRun()
Reading the Maven page, that should be enough to run it as a POJO test.
If I use this command line to invoke Maven:
mvn test -Dtest=com._3dmathpuzzles.krazydad.slitherlink.SolverTest
It does not
gt;
> mvn test -Dtest=dev.aspectj.*
>
> does not find any tests, but
>
> mvn test -Dtest=dev/aspectj/*
>
> does, is IMO simply a bug that ought to be fixed.
>
>
> Alexander Kriegisch schrieb am 06.02.2024 08:54 (GMT +07:00):
>
>> Bash:
>> mvn t
Sorry, hit the send button too quickly.
The fact that e.g. on Bash
mvn test -Dtest=dev.aspectj.*
does not find any tests, but
mvn test -Dtest=dev/aspectj/*
does, is IMO simply a bug that ought to be fixed.
--
Alexander Kriegisch
https://scrum-master.de
Alexander Kriegisch schrieb am
Bash:
mvn test -Dtest=dev.aspectj.MyO*
Windows Cmd/PowerShell:
mvn test "-Dtest=dev.aspectj.MyO*"
--
Alexander Kriegisch
https://scrum-master.de
Gary D. Gregory schrieb am 05.02.2024 22:22 (GMT +07:00):
> Hi All:
>
> mvn clean test -Dtest=org.apache.commons.compress.harm
Mon, 5 Feb 2024, /sebb/:
Under Windows,
mvn test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.ArchiveTest
fails with
Unknown lifecycle phase
".apache.commons.compress.harmony.pack2000.tests.ArchiveTest".
but the following works:
mvn te
There appears to be a different syntax for wild-card matching.
On macOS, the following works:
mvn test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.ArchiveTest
but
mvn test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.*
fails with
No tests matching pattern
Yep, slashes work. The double quoting gives a syntax error.
TY.
Gary
On 2024/02/05 15:53:41 Stanimir Stamenkov wrote:
> Mon, 5 Feb 2024, /sebb/:
>
> > That looks like a Windows quoting issue; Windows does not like '.' in
> > parameter values
> >
> >
Mon, 5 Feb 2024, /sebb/:
That looks like a Windows quoting issue; Windows does not like '.' in
parameter values
Try
mvn clean test -D"test=org.apache.commons.compress.harmony.unpack200.tests.*"
Dot (.) doesn't appear a standard delimiter on Windows:
* https://ss
That looks like a Windows quoting issue; Windows does not like '.' in
parameter values
Try
mvn clean test -D"test=org.apache.commons.compress.harmony.unpack200.tests.*"
On Mon, 5 Feb 2024 at 15:25, Gary D. Gregory wrote:
>
> Forgot to s
ws 10", version: "10.0", arch: "amd64", family: "windows"
Gary
On 2024/02/05 15:22:09 "Gary D. Gregory" wrote:
> Hi All:
>
> mvn clean test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.*
>
> gives me:
>
> [INFO
Hi All:
mvn clean test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.*
gives me:
[INFO] --- surefire:3.2.5:test (default-test) @ commons-compress ---
[INFO]
[INFO] BUILD FAILURE
[INFO
Hello Siddharth
Le 2023-10-13 à 00 h 02, Siddharth Jain a écrit :
IIUC, this is a separate issue. At minimum we need to make the
behavior of compile vs. testCompile consistent. Currently it is not.
Understood, but what I think is the common point is that Maven currently
uses heuristic rules
Hi Martin,
Thanks for your response. please see inline:
> Which approach did you choose for the tests? One approach is to
> duplicate the module-info.java file in the test directory [1], but this
> is not the only way.
>
Yes, that is the approach I took. Basically, the test code i
Hello Siddharth
I do not have a precise answer to your question, but below is a few notes.
Le 2023-10-12 à 23 h 07, Siddharth Jain a écrit :
I have observed the maven-compiler-plugin behaves differently for test
vs. main compilation.
Which approach did you choose for the tests? One approach
Hello,
I am building a project that uses modules (JPMS)
I have observed the maven-compiler-plugin behaves differently for test vs.
main compilation. I have a project and the main compilation works but the
test code does not compile. when i looked at the logs, i see during the
test-compile phase
> > Just to add, I am not sure if this is due to concurrent file access.
> Please check the attached screenshot of the console logs. There it is
> saying Test Run 5 but the AirInvoiceServiceTest contains only 1 test. And
> also the report shows random data. For example, sometimes it s
is saying Test
> Run 5 but the AirInvoiceServiceTest contains only 1 test. And also the report
> shows random data. For example, sometimes it says Test Run 5 , sometimes it
> says Test Run 2, etc.
>
> On Wed, Sep 13, 2023 at 12:11 PM Debraj Manna
> wrote:
>>
>>
Just to add, I am not sure if this is due to concurrent file access. Please
check the attached screenshot of the console logs. There it is saying Test
Run 5 but the AirInvoiceServiceTest contains only 1 test. And also the
report shows random data. For example, sometimes it says Test Run 5
ing?
> > >
> > > Thanks
> > >
> > > On Tue, Sep 12, 2023 at 5:16 PM Olivier Lamy wrote:
> > >
> > >> Maybe concurrent access to files in surefire
> > >> I'm using this extensively but only with 3 max parallel test.
> >
12, 2023 at 5:16 PM Olivier Lamy wrote:
> >
> >> Maybe concurrent access to files in surefire
> >> I'm using this extensively but only with 3 max parallel test.
> >> Can you try
> >> junit.jupiter.execution.parallel.config.fixed.parallelism=3
>
?
>
> Thanks
>
> On Tue, Sep 12, 2023 at 5:16 PM Olivier Lamy wrote:
>
>> Maybe concurrent access to files in surefire
>> I'm using this extensively but only with 3 max parallel test.
>> Can you try
>> junit.jupiter.execution.parallel.config.fixed.parallel
Olivier
Can you please let me know what version of Surefire and JUnit5 you are
using?
Thanks
On Tue, Sep 12, 2023 at 5:16 PM Olivier Lamy wrote:
> Maybe concurrent access to files in surefire
> I'm using this extensively but only with 3 max parallel test.
&g
Maybe concurrent access to files in surefire
I'm using this extensively but only with 3 max parallel test.
Can you try
junit.jupiter.execution.parallel.config.fixed.parallelism=3
And see if you still have the issues.
If not and if increasing this number is causing the issue. This sound
l
junit.jupiter.execution.parallel.mode.default=same_thread
junit.jupiter.execution.parallel.mode.classes.default=concurrent
I am observing the surefire reports that are getting generated are not
correct
I have a test class named
com.spotnana.servicetests.backoffice.invoicing.AirInvoiceServiceTest
contains just a single test
Hi Mark,
I ran into a similar problem today, July 12th.
In the logback project in order to test support for jigsaw/jpms in
maven-module 'x', we create a maven-module called x-blackbox. The
x-blackbox module contains junit5 tests under src/test/java and without
a src/main folder.
f the
tests in one module rather than having a src/test/java in each. This
works fine, except for the fact that I have to maintain duplicate module
descriptors in the src/main/java and src/main/test directories of the
*.tests module, and I also have to maintain a shadow package hierarchy
in src/main
you can also tell JUnit 5.9.2 to execute tests in parallel:
https://junit.org/junit5/docs/5.9.2/user-guide/index.html
Nils.
Op 29 mei 2023 om 16:13 heeft Debraj Manna
het volgende geschreven:
I updated by command like below
mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
But I am o
ted to mention
> that you can also tell JUnit 5.9.2 to execute tests in parallel:
> https://junit.org/junit5/docs/5.9.2/user-guide/index.html
>
> Nils.
>
> > Op 29 mei 2023 om 16:13 heeft Debraj Manna
> het volgende geschreven:
> >
> > I updated
; I updated by command like below
>
> mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
>
> But I am observing that all my test classes are being executed in
> ThreadStreamConsumer
>
> [ThreadedStreamConsumer] [INFO] Running
> com.spotnana.servicetests.p
I updated by command like below
mvn test -Dorg.slf4j.simpleLogger.showThreadName=true
But I am observing that all my test classes are being executed in
ThreadStreamConsumer
[ThreadedStreamConsumer] [INFO] Running
com.spotnana.servicetests.profile.ProfileCreatePersonalUserTest
I want to execute test classes concurrently in the same JVM. So my
surefire-plugin config looks like below
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M7
$${surefire.forkNumber}
-Xms512m -Xmx${surefire.max.heap}
-XX:MaxDirectMemorySize
be careful with " module-info.test in your test directory"
it's not supported by all IDE
On Sun, 3 Jul 2022 at 15:57, Stanimir Stamenkov
wrote:
> Thank you for the wonderful reference and summary, Daniel!
>
> While I'm parsing the information along with all its re
I'd still appreciate more elaboration on your comments, but I guess what I'm
going to attempt is to add exclusions in my parent pom for ALL of the
junit-platform and junit-jupiter artifacts (because the spring starter
artifacts include all of those) and then iteratively test re
Inline.
> -Original Message-
> From: Karl Heinz Marbaise
> Sent: Friday, July 8, 2022 9:21 AM
> To: David Karr ; i...@soebes.de
> Cc: Maven Users List
> Subject: Re: JUnit 5 test suites not running again
>
> On 08.07.22 18:09, David Karr wrote:
> > Inlin
ing, but now I see that I'm back to the state where our
JUnit 5
> test suites are being ignored.
>
>>From what I understood, I had to ensure that
"junit-platform-runner" was
> excluded as a dependency. What I have seems to have done this,
Inline.
On Fri, Jul 8, 2022 at 8:17 AM Karl Heinz Marbaise
wrote:
> Hi,
>
> On 08.07.22 16:18, David Karr wrote:
> > I had gotten help here with our JUnit 5 transition, and I thought I had
> it
> > all working, but now I see that I'm back to the state where our JUni
Hi,
On 08.07.22 16:18, David Karr wrote:
I had gotten help here with our JUnit 5 transition, and I thought I had it
all working, but now I see that I'm back to the state where our JUnit 5
test suites are being ignored.
From what I understood, I had to ensure that "junit-platform-r
I had gotten help here with our JUnit 5 transition, and I thought I had it
all working, but now I see that I'm back to the state where our JUnit 5
test suites are being ignored.
>From what I understood, I had to ensure that "junit-platform-runner" was
excluded as a dependency.
is here:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html
TLDR:
1. you keep the one module-info.java in your main project
2. you add a module-info.test in your test directory with
appropriate command line entries for add-opens (to see your source
code) and add-reads (essentiall
dular-world.html
TLDR:
1. you keep the one module-info.java in your main project
2. you add a module-info.test in your test directory with appropriate command
line entries for add-opens (to see your source code) and add-reads (essentially
replacing the additional "requires")
On
I can't figure out what's the best practice or just proper way for
setting up a JPMS Maven project with test sources that have additional
Java SE module dependencies to those of the main sources.
I have the following basic project structure:
pom.xml
src/
├─ main/
Hello,
I recently published a simple Maven example with working tests and a modern
site skin: https://github.com/learning-maven/simple-plugin.
It uses the awesome integration test framework of Karl Heinz Marbaise. It
requires a few dependencies and plugins but the usage is quite
straightforward
write a plugin following TDD practices.
> > Tried to follow:
> >
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
> >
> > which already fails on maven archetype:create (generate works, but
> doesn't
> >
ng to write a plugin following TDD practices.
> Tried to follow:
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
>
> which already fails on maven archetype:create (generate works, but doesn't
> create a test case
Trying to write a plugin following TDD practices.
Tried to follow:
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/getting-started/index.html
which already fails on maven archetype:create (generate works, but doesn't
create a test case).
last published versi
On 2022/05/31 04:01:21 Lasse Lindqvist wrote:
> Hi. Would using *surefire-report:report-only* help you? (
> https://maven.apache.org/surefire/maven-surefire-report-plugin/report-only-mojo.html
> )
I don't see how:
* If I do mvn 'test' 'surefire-report:report-o
Hi,
Another idea - try use failsafe
Execution can be:
- failsafe:integration-test
- surefire-report:failsafe-report-only
- failsafe:verify
Probably you should change of failsafe.includes and bind
failsafe:integration-test to test phase
wt., 31 maj 2022 o 06:01 Lasse Lindqvist
napisał(a
for our Dockerized Java app.
> The way this pipeline works is we have separate steps for building our
> Docker image and for running our unit tests. The unit test step is supposed
> to output an HTML test report which is uploaded as a job artifact, and also
> return an error if the te
I'm trying to set up a Gitlab CI/CD pipeline for our Dockerized Java app. The
way this pipeline works is we have separate steps for building our Docker image
and for running our unit tests. The unit test step is supposed to output an
HTML test report which is uploaded as a job artifact
> something like;
>
>
>
> withJavaAgent
>
> -javaagent:C:\JARS\agent.jar
>
>
>
>
>
>
>
> maven-surefire-plugin
>
> ${myJavaAgent}
> -DtheGroup=${project.groupId} -DtheArtifact=${project.artifactId}
>
&g
to override on the command line it's; mvn test
-DmyJavaAgent="-javaagent:C:\JARS\agent.jar"
Or; mvn test -PwithJavaAgent
John
On Wed, 30 Mar 2022 at 06:45, Laurian Angelescu
wrote:
> I am working on a Java agent that instruments test suites and the code
> under test. The a
I am working on a Java agent that instruments test suites and the code
under test. The agent runs by invoking the following command on the command
line:
mvn test -DargLine="-javaagent:C:\JARS\agent.jar"
The apache surefire plugin takes care of running the tests and pushing the
-DargLin
failsafe-plugin and loading of resources
from (test-)jars
Hi Falko,
Unfortunately, I've tried disabling the modulePath ... that didn't seem to
disable this behavior and it continues to use the module path.
Also tried all sorts of classloaders, that I knew ... none of them worked.
Hi Falko,
Unfortunately, I've tried disabling the modulePath ... that didn't seem to
disable this behavior and it continues to use the module path.
Also tried all sorts of classloaders, that I knew ... none of them worked.
So, I even started adding module-info.java to my src/test/ja
Hi Christofer,
you might want to try disabling
https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#useModulePath
You could also try to use the TCCL instead
(Thread.currentThread().getContextClassloader()).
Cheers,
Falko
: Donnerstag, 27. Januar 2022 22:59
To: Maven Users List
Subject: RE: Problems with the maven-failsafe-plugin and loading of resources
from (test-)jars
Sorry for the double posting ... guess my mailserver had hickups and now I know
why I had to write it twice 😉
I think this version might be the
@maven.apache.org)
Subject: Problems with the maven-failsafe-plugin and loading of resources from
(test-)jars
Hi,
in the Apache PLC4X build we recently noticed that surefire and failsafe 2.22.2
were missing to pickup some of our tests, which we use with @TestFactory
annotation.
It turns out that when
our tests we usually load test-jars which contain test-resources which are
processed in our tests.
They are referenced by the module in this way:
org.apache.plc4x
plc4x-protocols-modbus
0.10.0-SNAPSHOT
tests
test-jar
test
In failsafe the test is unable
Bernd Eckenfels
wrote:
> We have one case in commons, there rhe -test JAR of VFS can be used by
> Providers to test their implementation. I did that for my custom provider,
> but it is a bit ugly. I think that’s mostly due to relying on some src
> files and also the JUnit setup whe
You can easily solve this.
Just create (N+1) module which contains test classes.
The N+1 module should inherit from the module N having normal sources.
The trick is to build module N, and then N+1.
On Fri, Jul 9, 2021 at 1:13 AM Brandon Mintern wrote:
> Tibor,
>
> Thanks for your
nd not to the other
> > module/s.
> > They were not designed to be inherited and it is logical because unit
> tests
> > have to test a small unit code where the unit is a method, class or a
> > module.
> > Integration tests are used to test the whole application which is
PM Tibor Digana wrote:
> The tests are dedicated to the module sources and not to the other
> module/s.
> They were not designed to be inherited and it is logical because unit tests
> have to test a small unit code where the unit is a method, class or a
> module.
> Integration
The tests are dedicated to the module sources and not to the other module/s.
They were not designed to be inherited and it is logical because unit tests
have to test a small unit code where the unit is a method, class or a
module.
Integration tests are used to test the whole application which is a
Thanks for the pointer to that conversation! Andreas described exactly my
issue in a much clearer and more concise way.
For now, test-jars seem to be the best path forward in spite of the
drawbacks. I'm considering writing a plugin to prototype the "stubs"
approach that I described
e.org%3E
The conclusion was also that there's no great way to accomplish this. I
think one good way to fix this issue would be to have Maven resolve
test-scoped dependencies transitively when you depend on test-jars, but
perhaps there's a good reason why that's not practical or not a good idea.
--
Andy Feldman
We have one case in commons, there rhe -test JAR of VFS can be used by
Providers to test their implementation. I did that for my custom provider, but
it is a bit ugly. I think that’s mostly due to relying on some src files and
also the JUnit setup when I remember correctly. But it did work
I did not have time to read it all but I have to say that even the first
point is bad.
Many people want to share test JAR as they initially think it is a good
idea. And then the problems would come.
sharing stubs? This domain/project may not fit to other domain/project, and
it creates dangerous
Hello all,
I'm running up against an issue that I'm sure has come up countless times.
How can we share test dependencies in a principled way? I would like to
configure our projects such that:
1. For a project *P*, its tests are associated with the project, so that
`mvn install
"" && ! -e "$path/$1" ]]; do
> path=${path%/*}
> done
> echo "$path/$1"
> }
> find-up "$@"
>
> So: this lets me run Maven from a subdirectory. Nice and convenient.
>
> I found that when I run Maven in this manner from s
t;" && ! -e "$path/$1" ]]; do
path=${path%/*}
done
echo "$path/$1"
}
find-up "$@"
So: this lets me run Maven from a subdirectory. Nice and convenient.
I found that when I run Maven in this manner from src/main/java, i.e. the
directory housin
6cff867d5d6a74941e5131a20a7301b89fae65d/src/it/projects/MJLINK-41_addoptions-11/pom.xml#L53
>
> - Ben
>
> Am Mi., 21. Apr. 2021 um 10:00 Uhr schrieb Zos ROTHKO :
> >
> > Hello Maven's users
> >
> > I have a problem about tracking the new snapshot version of
the new snapshot version of an jar
> artifact within the integration test running the maven-invoker-plugin.
>
> Each integration test project is using the snapshot version of the jar
> artifact as a runtime dependency of a 3rd party maven plugin. When there
> is a maven release
Hello Maven's users
I have a problem about tracking the new snapshot version of an jar
artifact within the integration test running the maven-invoker-plugin.
Each integration test project is using the snapshot version of the jar
artifact as a runtime dependency of a 3rd party maven p
Dependencies declared with scope=test in the original project
(google-cloud-storage) won't come in transitively, you'd have to copy/paste
them.
Ideally, if that use case were to be officially supported, the project
would have to publish the tests as a normal JAR at different coordina
I'm attempting to run the tests in a test jar rather than from source,
for reasons. That is, I set up the pom.xml like so to run the tests
that are bundled in
com.google.cloud:google-cloud-storage:test-jar:tests
org.apache.maven.plugins
maven-surefire-p
Hi Mukul, the problem with System.exit() can be in a library - dependency,
not only in your code and therefore the system manager has to be configured
in system property in order to find and confirm the hypothesis. T
Dňa pi 9. 10. 2020, 18:01 Enrico Olivelli napísal(a):
> Something like this:
>
Something like this:
public class NoExitSecurityManager extends SecurityManager {
private final SecurityManager wrapped;
public static void setup() {
Policy.setPolicy(new Policy() {
final Permissions pc = new Permissions();
{
pc.add(new A
On Wed, Oct 7, 2020 at 9:09 PM Enrico Olivelli wrote:
> A good approach to workaround the presence of third party libraries that
> call System.exit is to set a SecurityManager that prevents calls to
> System.exit.
I'll find it helpful, if you may share any code sample how to do this?
--
Reg
A good approach to workaround the presence of third party libraries that
call System.exit is to set a SecurityManager that prevents calls to
System.exit. I did it a few times with good results.
You will have to allow well known libraries like Eclipse test runner or
Surefire itself
Just my 2 cents
Hi Tibor,
On Wed, Sep 30, 2020 at 5:03 PM Tibor Digana wrote:
> Usually these errors appear in the test itself or the *libraries*.
> As for instance, we found out that a Spring's library is implementing Kafka
> stuff calling the "Runtime.getRuntime().halt( )".
> Th
Hi Mukul,
Sorry for my late reply.
I am checking pending emails.
Usually these errors appear in the test itself or the *libraries*.
As for instance, we found out that a Spring's library is implementing Kafka
stuff calling the "Runtime.getRuntime().halt( )".
The same bad thing
I also found out how to move the Surefire config back into the root POM
(see commit [2]). I must have been blind before not to see that the
plugin configurations should to into the sections of
each profile instead of declaring the plugins as active in the root POM.
Now there is no more duplicatio
de
Julia Boes schrieb am 03.09.2020 22:11 (GMT +07:00):
>> So what I suggest is to not just run a single test on JDK 14 but to run
>> all tests, just like you compile all tests.
>
> I had originally expected more errors when compiling/running with JDK 14 but
> that didn&#
Hi Alexander,
Thanks for looking into this again.
So what I suggest is to not just run a single test on JDK 14 but to run
all tests, just like you compile all tests.
I had originally expected more errors when compiling/running with JDK 14 but
that didn't turn out to be the case - goo
I added another sample commit:
https://github.com/kriegaex/kryo/commit/c1d8729748ddb0e6367d440bed57f58aa64d534a
Quoting the commit comment:
Move Surefire configuration to root POM and streamline
Now only the Compiler plugin configuration for test compilation is
duplicated in submodules kryo
superset of JDK < 14. You
insisted on mutual exclusivity against my recommendation. But now in
your description I see that you seem to describe a behaviour which is
more like the superset thing I had in mind, e.g. for JDK 14 you also
compile the other tests, not just the JDK 14 test you wish to
zerTest (t) requires jdk 14 --enable-preview for
compilation and test run.
$ mvn clean && mvn install
with jdk-14.0.1 compiles t with --enable-preview and all other tests
without the flag
with jdk-11.0.8 compiles all tests but t Similarly, I tried to set
executions for the test goal to ach
Julia Boes schrieb am 27.08.2020 15:09 (GMT +07:00):
>> I cannot say for sure, but probably you just copied & pasted my
>> plugin configurations into the parent POM's section instead
>> of -> , consequently kicking off test
>> compilation from the par
Hi Alexander,
I cannot say for sure, but probably you just copied & pasted
my plugin configurations into the parent POM's section instead
of -> , consequently kicking off test
compilation from the parent. I guess you want to change that.
That's exactly what I did. Moving
1 - 100 of 3445 matches
Mail list logo
