My proposal is to follow these steps.
It might be faster to split this activity to multiple ones and solve them
separately in branches in parallel but finish it in release 2.20.2,
otherwise the release 2.20.1 will be quite postponed.
Maybe we should split SUREFIRE-1262 in to sub-tickets.
It's easier to test small ticket and fix small bunch of changes as well.
Each sub-ticket should have own unit and IT tests.
*1.* We with Michael Osipov made a prototype  for an issue recognized on
Basically this prototype had one goal, to execute CLI using Java Process,
and later with maven-shared-utils and isolate the issue.
I believe we should follow similar principle regarding Jigsaw on Surefire
as well and execute a test with CLI in separate project. It should include
all dependencies projects, etc. We will test it on Unix-like and Windows OS.
I expect an issue on Windows where Long Windows paths on file system will
crash the CLI. If this happens, we have to talk with Oracle again and
clarify. I am working with @dev on same issue with long paths and the
solution seems to be to copy *.jar to system default-tmp directory because
the path is use to be short enough on Windows.
*2.* Currently we have to filter test classes in Maven process and load
classes via IsolatedClassLoader. Basically it loads classes and scans
annotations @RunWith, @Test and super class TestClass of JUnit and TestNG.
Then these classes are scheduled in Provider in plugin process or in forked
This concept is not ideal and should be changed otherwise we have to
implement Java 9 ClassLoader.
My idea was to send a command to Provider and Provider has to examine the
test classes, send answer back to Plugin and plugin says yes to run it or
no to forget it.
This way we cove over two issues:
*A:* static initializers of test class is not run twice.
*B:* no need to implement Java 9 ClassLoader
This mechanism is planned in next release 2.20.2, *see * => my work
started on December 2016 and now appears in *branch * almost complete.
*3.* Change documentation on kind of Java 9 build and say that
*META-INF/MANIFEST.MF* and environment property *CLASS_PATH* set on CLI of
forked process is obsolete and not in use and therefore certain
configuration parameters are implicitly inactive.
*4.* CLI (maven-shared-utils) used currently in class *ForkStarter.java*
need an abstraction because:
*A:* execution with Jigsaw and implement another class
*B:* use of TCP sockets instead of standard-output, input, error of native
processes which are currently problematic. The implementation with sockets
may go in much later release but no need to rework Jigsaw staff because the
abstraction would prevent from doing so.
---------- Forwarded message ----------
From: Robert Scholte <[hidden email]>
Date: Tue, Aug 1, 2017 at 6:45 PM
To: Tibor Digana <[hidden email]>
I've been contacted by Alan Bateman, main developer of the Oracle Jigsaw
He's having a look at the status of all projects and was wondering about
In fact, he offered his help.
bq. I assumed the challenge for test execute would be getting the CLI
options right. I would expect it will end up like this:
-m junit/org.junit.runner.JUnitCore <test-class>
which is complicated. The `--add-reads` option will depend on which test
framework is used. The `--add-exports` options will be repeated for each
package contains tests invoked by the test framework.
I'm happy to engage with Tibor to help get this right.
What do you think? Should we pick this up with the three of us?
|Free forum by Nabble||Edit this page|