smack-xmpparser-xpp3/build.gradle specifies both xpp3_min and xpp3 as dependencies; this causes duplicate class runtime exception when build under android studio for aTalk.
aTalk build.gradle uses the following to avoid duplication during as built. However found that the
“all*.exclude” statement can cause unexpected behavior from android studio; and would like to avoid use of this type of statement.
======== atalk build.gradle =========
configurations {
all*.exclude group: 'xpp3', module: 'xpp3_min'
// no further required???; found also fixes: Could not load org.igniterealtime.jbosh.HTTPSender implementation with fdroidDebug apk
// all*.exclude group: 'org.apache.httpcomponents', module: 'httpclient'
}
========== smack-xmlparse-xpp3 build.gradle =======
description = """\
Smack XML parser using XPP3."""
ext {
xpp3Version = "1.1.4c"
}
dependencies {
api "xpp3:xpp3_min:$xpp3Version"
implementation "xpp3:xpp3:$xpp3Version"
api project(':smack-xmlparser')
testCompile project(path: ":smack-xmlparser", configuration: "testRuntime")
}
======== aTalk built runtime exception ==========
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':aTalk:checkPlaystoreDebugDuplicateClasses'.
> 1 exception was raised by workers:
java.lang.RuntimeException: Duplicate class org.xmlpull.mxp1.MXParser found in modules xpp3-1.1.4c.jar (xpp3:xpp3:1.1.4c) and xpp3_min-1.1.4c.jar (xpp3:xpp3_min:1.1.4c)
Duplicate class org.xmlpull.v1.XmlPullParser found in modules xpp3-1.1.4c.jar (xpp3:xpp3:1.1.4c) and xpp3_min-1.1.4c.jar (xpp3:xpp3_min:1.1.4c)
Duplicate class org.xmlpull.v1.XmlPullParserException found in modules xpp3-1.1.4c.jar (xpp3:xpp3:1.1.4c) and xpp3_min-1.1.4c.jar (xpp3:xpp3_min:1.1.4c)
Go to the documentation to learn how to <a href="d.android.com/r/tools/classpath-sync-errors">Fix dependency resolution errors</a>.
You need to exclude xpp3_min, there is really no way around. I have never heard or experienced unexpected behavior caused by this. Do you have a reference or example?
Actually the example is given in the first comment:
The latest android SDK does not include httpclient. So I can remove the below statement. Otherwise it causes problem in the apk built for fdroid as mentioned in the link above.
Earlier I also faced problem with aTalk because of the exclude statements. Eventually settled on something proposed by the android team. There are weird problems created with exclude statements. So it possible, would like to avoid using it.
Actually I also observed that some of the org.apache methods are also being defined in android SDK. It seems that SDK methods take priority over app included methods. I see that jbosh jar uses org.apache libraries, wonder if smack team is thinking to move to something else e.g. OKHttp, to avoid library conflict problem or a need to add exclude again when AS complaint duplicate exception again.
In aTalk current source, it too faces some problem with SSLSocketFactory class, it is being defined in android SDK android.jar and org.apache.httpcomponents:httpclinet lib. Android studio prefers class in SDK over external defined apache library. Thinking of porting aTalk source to somethings else, preferably to be the same as smack.
I also faced problem with QName class AbstractMethodError. I see that the class is being defined in android SDK android.jar as well as smack referenced java 1.8 standard library.
According to online search, it mentions that the problem is due to two different versions of libraries are being defined in project POM file.The problem only happens when running aTalk on Note-5 (API-21) but not Note-10/8 (API-28).
online reference:
I am still struggling to find a clean solution to overcome this problem. Any recommendation is much appreciated.
11-11 10:08:31.159 24354-24722/org.atalk.android E/(UtilActivator.java:90)#uncaughtException: An uncaught exception occurred in thread = Thread[Smack Reader (0),5,main] and message was: abstract method "javax.xml.namespace.QName org.jivesoftware.smack.packet.FullyQualifiedElement.getQName()"
java.lang.AbstractMethodError: abstract method "javax.xml.namespace.QName org.jivesoftware.smack.packet.FullyQualifiedElement.getQName()"
at org.jivesoftware.smack.AbstractXMPPConnection.addStreamFeature(AbstractXMPPConnection.java:1785)
at org.jivesoftware.smack.AbstractXMPPConnection.parseFeatures(AbstractXMPPConnection.java:1733)
at org.jivesoftware.smack.AbstractXMPPConnection.parseFeaturesAndNotify(AbstractXMPPConnection.java:1743)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1100(XMPPTCPConnection.java:132)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:952)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:881)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:901)
at java.lang.Thread.run(Thread.java:818)
That is true for a significant part of the types in the java.* and javax.* package namespace. The Android runtime tries to stay compatible with the Java SE runtime and hence declares, defines and provides a lot of classes the Java SE rt.jar provides.
I suspect the problem here could be some linkage error, like mismatching versions.