Hi Benedikt,
I noticed a new thread on the jigsaw mailinglist[1].
It is close related to the issue I have: you don't want to "patch" java
with arguments just to allow split packages for certain modules. I really
hope that by chaining classloaders we can prevent this.
Robert
[1]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010233.html
On Tue, 22 Nov 2016 20:51:44 +0100, Benedikt Ritter <[email protected]>
wrote:
Hello again,
Benedikt Ritter <[email protected]> schrieb am Fr., 18. Nov. 2016 um
08:40 Uhr:
Hi,
I had the pleasure to meet Robert Scholte and Herve Boutemy here at
ApacheCon in Seville. We talked al little bit about the progress of the
JUnit 5 integration. This let us to create two sample projects which may
indicate problems both within surefire and within JUnit. We're still
investigating whether this are really issues. I'm in contact with the
JUnit
team to find out what they might need to fix and I'm reaching out to the
Maven community to find out what we need to fix.
The first sample project is https://github.com/britter/junit-cl
It uses the configuration described at
http://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-engines-configure
to
configure the JUnit Jupiter test engine to run some tests. What we want
to
find out is, whether the test class can see the classes of the test
engine
(which they should not) and whether the production classes can see the
test
classes or the test engine classes (which they should not). This is what
Robert called the "classpath problem", because everything in mangled
together in one classpath. This probably needs to be fixed inside JUnit.
Unfortunately currently the configuration described in the JUnit docs
does
not work. So instead of configuring the jupiter engine, it just reports
that it can not find any engines.
I've fixed the problem. The build now works an it fails for the right
reason :-)
I tried to explain this problem to Marc Philipp from JUnit but I failed
to
understand why this is an issue at all. I mean, okay it may be cleaner if
we had separate classloaders, but what would be a really error scenario a
user might encounter when the same Classloader loads production and test
classes?
The second example is https://github.com/britter/junit-java9 and it is
about JUnit and Java 9 modules. Robert was sure that there is a problem
with modules and that it needs to be fixed in surefire. However we did
not
get that example working at all, so Robert decided to investigate this
some
more when he is back home.
Here is what we expect to fail: Suppose we have a package com.example
with
some classes. Then we add some tests in src/test/java in the same
package.
When we compile this and execute the tests, Java 9 should report that
there
are several jars providing classes for the com.example package.
I've also applied the fix from above to the java9 example.
Marc Philipp and I agreed upon tackling the Java 9 issue from both (maven
and junit) sites. He will talk to Sam Brannen from the Spring project and
ask them how they do reflection in Java 9. Furthermore he things about
writing to the OpenJDK Mailing list.
On the Maven site, Robert wanted to take a look into this. @Robert: Did
you
have some time to investigate this some more?
Regards,
Benedikt
Hope I was able to give you a heads up on what we were talking about :-)
Regards,
Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
