Extract sources into modules

[juherr]

From @missedone on testng-team/testng-eclipse#91

i think it would be a good chance to make testng into multi module:

• testng
  • testng core
  • remote testng with object serialization
  • remote testng with json serialization
  • utils depends on snakeyaml
  • etc.

this can benefit the user that they can better control the dependencies, e.g. for most people they only need testng-core so that they can have a clean dependency tree that wont import unexpected dependent lib (e.g. snakeyaml)

[juherr]

I think the idea is good but will be a big change.

And we can still have an aggregated artifact which will keep the current behavior.

[cbeust]

Not sure there is a big upside for users there...

[missedone]

@cbeust
when I looked into the "SocketException: Broken pipe" issue testng-team/testng-eclipse#91 of testng eclipse plugin, I think the root cause is there is version mismatch, or how to say, servialVersion incompatibility:

java.io.InvalidClassException: org.testng.remote.strprotocol.TestResultMessage; local class incompatible: stream classdesc serialVersionUID = 1237363180433975833, local class serialVersionUID = -4157150777889117479

so my initial solution for this is to make the RemoteTestNG of Eclipse Plugin consistent (or compatible) with the RemoteTestNG of Runtime TestNG.

to achieve this

• option-1, create new class extends RemoteTestNG and take it as the agent for communication between plugin and testng runtime
• or, option-2, extract remote testng into it own module and make it as the agent for communication between plugin and testng runtime. to make sure the new RemoteTestNG module loaded by runtime, we can put it on front of the classpath to make sure it's loaded.

i prefer option-2, since with this approach:

1. it's possible for us to allow the user still use the old version of testng as the runtime since the plugin has control the agent for communication (and always make sure it compatibly works).
2. also, if we put more feature to RemoteTestNG and make it for plugin, we don't need as people to upgrade runtime TestNG, etc.
3. we won't duplicate the effort of maintain two copy of RemoteTestNG

if you agree to modularize RemoteTestNG, naturally, we can think about the possibility of modularizing whole TestNG project, as i remember SnakeYaml also introduced some version conflict trouble to the users before, though modularizing does not solve the version conflict at all, but at least reduce the possibility since i believe most of the people won't this testng yaml features too much (just my personal guess:()

[cbeust]

Before digging into this, couldn’t we simply add the missing
serialVersionUUID to the classes causing this problem?
​

Cédric

[missedone]

well, we can add the missing serialVersionUUID to current master branch, but we can't change the already released testng, right? so i doubt that if only add the serialVersionUUID at one side (aka, plugin side), we will still get the InvalidClassException.

[juherr]

@cbeust What do you think to have a "next" branch for more aggressive refactoring and planned to be released once ready for TestNG 7.0? And keep the current master with quick bug fixes?

[krmahadevan]

@juherr - Now that TestNG is actually split into multiple modules, can we consider closing this issue ?

[juherr]

I think we can go further but we can close this issue :)