issue #91: SocketException: Software caused connection abort

[missedone]

the solution is as i stated in testng-team/testng#777 that use the plugin embedded testing-remote.jar as the agent for communicating TestNG runtime with plugin

the testng-remote source code is splitter out from the main testng git repo: https://github.com/missedone/testng-remote

[missedone]

add remote testng jar file at the very begining to make sure this is loaded in prior of the user's testng.jar

[missedone]

Hi @cbeust @juherr
with this solution, I had some tests against different version of testng, it turns out that current testng-remote is compatible with 6.5.1 or above, but failed with 6.3.1 or below.

i think what @juherr proposed might solve this. but i'm not sure if we really want to support that old version, or shall we add minimum supported testng version in plugin?

[juherr]

I suppose 6.5.1 will be enough but more could be fun.
The question is: is it possible to find easily the testng version from classpath?

[missedone]

ah, good question, i'm afraid we can't, org.testng.internal.Version.VERSION only came since 6.8.1 and not really synced with the release version.

[JnRouvignac]

I think it is possible to configure maven to output a MANIFEST.MF file with all the build information. Including when using the mvn release plugin.

[juherr]

Yep, good idea. I checked and the Implementation-Version is available since 5.0.
And we can use Main-Class: org.testng.TestNG to find the appropriate MANIFEST.MF in classpath.

[missedone]

quoted from @juherr

And why not having a module by API version (in order to have the appropriate testng dependency and have compile time check), load the appropriate facade by reflexion depending on the version and produce an all in one jar with all facade? A bit like what surefire is doing.

generally, i think it's the right approach. But when we're talking about API, it means both the Java Interfaces (e.g. methods signatures) but also the data protocol spec, after look at the version of 6.3.1, my current concern is, 6.3.1 is missing the "instanceName" property in TestResultMessage which means it breaks the data protocol, I'm not sure if this will work or not without "instanceName"...

[missedone]

or, try to make it clear, let's say, the solution need consider at both the plugin side and TestNG runtime side. @juherr, are we both holding the assumption that, there will be only one version of remote testng at plugin side which will communicate with the facade remote testng (which will delegate the request to the specific version of remote testng) at TestNG runtime side?

otherwise, i might have more concerns that let's talk about them later.

[juherr]

Yes, we are agree.

eclipse -> remote api -> remote impl x -> testng x (maybe x+1, x+2, ... too)
                      -> remote impl y -> testng y (maybe y+1, y+2, .. too)

But it's clearly a "fun" feature with a low priority IMO. We just have to think a bit about it in order to have an architecture which will permit it later.

[missedone]

yes, agreed.

@cbeust
what do you think if this PR, this solution, only support testng 6.5.1 or above? that says the minimum testng version is 6.5.1 since the change.

[cbeust]

I'm fine with supporting only 6.5.1+.

[cbeust]

Any reason why this PR removes the JUnit 4 jar file?

[missedone]

junit.jar was used by the plugin, now plugin depends on the existing org.junit plugin so that we can save the dist plugin size.
this junit jar is not used at runtime, so it is safe to remove.

[missedone]

@cbeust
how do we proceed this PR?
if it's OK to merge, we will have other thing to think about:

1. shall we move testng-remote to your official testng github, just like cbeust/testng? so that we all maintain the same git repo
2. do you think need to remove the remote package out of testng git repo to avoid duplication with testng-remote?

[juherr]

1. I propose testng-team group instead :)
2. +1 to remove duplication once released

[cbeust]

My suggestion:

• Move the testng-remote project to the testng-team org as suggested by @juherr
• Once this is done, I'll merge this PR

Is everybody okay with this?

[missedone]

yeah, sounds good:)
the new repo is here: https://github.com/testng-team/testng-remote

[cbeust]

Thanks, @missedone.

Everybody on board with merging this PR?

[juherr]

👍