[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.

[GitBox <gi...@apache.org>]

Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-599196530
 
 
   Thx for testing it, I will reproduce the error with your project.
   Maybe it would be worth to enable TCP/IP by default shortly on my local PC and see all test failures. We have cc 800 ITs.
   The config parameter `forkNode` was chosen as non-boolean for several reasons:
   
   - we do not want to be overloaded team with user's requests. The attribute `implementation` would make us disburden, see #74 and the comment from Andreas. That's why we have a single parameter with default implementation which can be switched to user's impl. Instead string value as `stdio` is not a class. With the string value, you closed your door for further and readable configuration of the channel because you cannot add nested elements with for instance some custom elements that we do not know in advance yet. With this style you have nice structural written instead of writing/encoding all (class name, communication attributes, port, IP, token) in one string value. This way, the nested elements would become setters/getters of the `forkNode`. The class `ForkNodeFactory` must have no-args constructor to be "injectable" but the setters would pass the custom data other way than the constructor which solves the problem too.
   - we can support `remote JAR`. Adding more and more configuration parameters is not currently the way to go. If we can encapsulate few related config parameters, why not to do it. Here in the case of `forkNode` the streams are related to the process executing the CLI. If such a requirement comes that the JAR wants to be executed remotely, then most probably the user would like to change the communication protocol with higher security level and the `CommandlineExecutor` would be added to the factory of fork nodes.
   - I think that there would small number of projects which will use TCP/IP in the beginning. After we complete the version 3.0.0, we should use TCP/IP as the default implementation and then there would be some project which would just use "remote JAR" or distrubuted execution over virtual nodes like VMs or Docker, or so. But this would be our responsibility. And the rest of the world would be fine with the default TCP/IP embedded in Surefire.
   

----------------------------------------------------------------
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, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services