search

testng-team / testng-eclipse

Eclipse plug-in for TestNG
https://testng.org
194 stars 164 forks source link

Can't run offline with Eclipse Plugin v 7.x and system-under-test v 6.x #487

Closed ahgittin closed 4 years ago

ahgittin commented 4 years ago

A recent update to plugin (last 6 months) has broken offline use.

Previously if I was offline, testng from Eclipse would run fine. Now it complains that it cannot reach testng.org. Full trace below. It works fine if I'm online.

I'm guessing the problem is it is trying to download the DTD. But I think testng skips that for the default DTD which is what it looks like it should be using. I am not using any custom XML template (although I have tried, but it doesn't seem to help). The problem may have been introduced by https://github.com/cbeust/testng-eclipse/commit/3acbb6c764c14a0ca75b7e33be0fcd6c4341510e#diff-7b0172117db33babc8855d1187ec0607R41 -- or perhaps it is already fix but not released yet. (If so please accept apologies.)

Using version 7.1.1.202003100345 with maven on OSX. Remote testng tested with 6.10, 6.14.3, and 7.1.0.

Full trace:

[RemoteTestNG] detected TestNG version 6.14.3
org.testng.TestNGException: java.net.UnknownHostException: testng.org
    at org.testng.TestNG.parseSuite(TestNG.java:327)
    at org.testng.TestNG.initializeSuitesAndJarFile(TestNG.java:348)
    at org.testng.TestNG.initializeEverything(TestNG.java:995)
    at org.testng.remote.support.RemoteTestNG6_12.initialize(RemoteTestNG6_12.java:22)
    at org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:98)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:251)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:77)
Caused by: java.net.UnknownHostException: testng.org
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:607)
    at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666)
    at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173)
    at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:463)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:558)
    at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264)
    at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1162)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1056)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:268)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:647)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1304)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1270)
    at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:264)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1161)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1045)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:959)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
    at org.testng.xml.XMLParser.parse(XMLParser.java:38)
    at org.testng.xml.SuiteXmlParser.parse(SuiteXmlParser.java:16)
    at org.testng.xml.SuiteXmlParser.parse(SuiteXmlParser.java:9)
    at org.testng.xml.Parser.parse(Parser.java:152)
    at org.testng.xml.Parser.parse(Parser.java:233)
    at org.testng.TestNG.parseSuite(TestNG.java:295)
    ... 6 more
ahgittin commented 4 years ago

The issue seems to be:

Workarounds

Bumping TestNG in my project to 7.x does seem to resolve the problem. (It just needs some TLC to make the change apply in Eclipse, that observation in the initial report was wrong. However there are a lot of annoying assertEquals(double, double) checks which now give errors about ambiguity with assertEquals(Object, Object) -- so not a great workaround.

Using the v6.14.3 TestNG Eclipse Plugin works fine with Eclipse 2020-03. This is what I'll do for now.

I couldn't find any userland way to make the 7.x Eclipse plugin work with 6.x target offline. The doctype in the template is ignored.

Fix Suggestions

I couldn't easily tell whether the plugin is able to detect the remote TestNG version prior to creating the suite XML -- if so, then of course falling back to the http DTD URL if the version is detected as <7 is the nicest solution.

If that's not straightforward then maybe a preference, or respect the DOCTYPE from the template (but Java/XML doesn't make that very nice to do).

This seems a good use case for publicId in the DOCTYPE, with a backport to 6.x which understands that.

Or leave it ... y'all do a good service by making TestNG, it's worth a lot more than I've paid for it :) and downgrading/upgrading is easy enough.

missedone commented 4 years ago

@ahgittin , pls install the latest release https://github.com/cbeust/testng-eclipse/releases/tag/7.1.1.202003100345

it fixes the DTD https url issue, but for existing test launch configuration, you may have to delete and re-create it if you still have the issue.

Zlika commented 4 years ago

Hi! I use Testng eclipse plugin 7.2.0.202005051752 and I still face this problem.

missedone commented 4 years ago

if there's already launch configuration there, pls remove it and re-run again. if you use custom xml suite template, pls make sure use https DTD, and re-run

Zlika commented 4 years ago

Hi! I deleted the eclipse launch configuration but the problem is still present. I do not explicitly use a custom xml suite template, it's a maven project imported into eclipse using m2e.