Since 2f667f95a ("gradle: Remove archives configuration") the
:smack-repl:printXmppNioTcpConnectionStateGraph
JavaExec task failed with
> Task :smack-repl:printXmppNioTcpConnectionStateGraph FAILED
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.jivesoftware.smack.SmackConfiguration.getVersion(SmackConfiguration.java:108)
at org.jivesoftware.smack.AbstractXMPPConnection.<clinit>(AbstractXMPPConnection.java:187)
at org.igniterealtime.smack.smackrepl.StateGraph.main(StateGraph.java:37)
Caused by: java.lang.IllegalStateException: Could not parse Smack configuration file
at org.jivesoftware.smack.SmackInitialization.<clinit>(SmackInitialization.java:100)
... 3 more
Caused by: java.lang.IllegalStateException: Could not load a XmlPullParserFactory via Service Provider Interface (SPI)
at org.jivesoftware.smack.xml.SmackXmlParser.getXmlPullParserFactory(SmackXmlParser.java:34)
at org.jivesoftware.smack.xml.SmackXmlParser.newXmlParser(SmackXmlParser.java:53)
at org.jivesoftware.smack.util.PacketParserUtils.getParserFor(PacketParserUtils.java:76)
at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:144)
at org.jivesoftware.smack.SmackInitialization.processConfigFile(SmackInitialization.java:139)
at org.jivesoftware.smack.SmackInitialization.<clinit>(SmackInitialization.java:97)
... 3 more
because no XmlPullParser was registered via SPI. The 'archives'
configuration which was removed with 2f667f95a ("gradle: Remove
archives configuration"), previously pulled in the parser.
Just like smack-android delcares a dependency on smack-xmlparser-xpp3,
smack-java7 should declare a dependency on smack-xmlparser-stax.
Since using a pipe, as we did previously would not error the target if
the first command in the pipe fails.
It is still far from ideal, since the dot file is also generated if
the gradle command fails. At some point, this should probably become
part of gradle build step instead of shelling out to a Makefile.
and FileTestUtil in favor of commons-io. This is required because
Eclipse won't put src/test code into the classpath of src/main
code (even though gradle was configured with an according
dependency).
gradles compile command (which is deprecated and should be replaced with implementation) includes the arguments resources into the result jar.
That means that smack-android will contain resources found at the android boot classpath.
This results in a +~11mb increase in size of the resulting apk when including Smack as a composite build. The increase comes from 11mb of Android resources, mainly drawables.
compileOnly (formerly provided) on the other hand will assert that the android.jar classes are provided by the system, which is probably what we want in this case.
there is no reason why we want to store the bytes of the base64
encoded string. Simply store the string itself.
Also add a convenience method to get the decoded bytes of the PubKey.
- Reduce the amount of types that are subtypes of NamedElement. See
javadoc of NamedElement for rationale.
- Work more with XmlEnvironment in XmlStringBuilder.
- Some minor changes to XmlStringBuilder API.
to ensure that javadocAll works correctly. A nice side-effect, this
also ensures that the package-info.java symbolic links are still
correct and haven't been replaced by some IDE or editor with the
content of the link target.
This is needed for javadocAll since otherwhise there will be
smack-core/src/main/java/org/jivesoftware/smack/package-info.java:21:
warning: a package-info.java file has already been seen for
package org.jivesoftware.smack
warnings.
by using PubSubManager.tryToPublishAndPossibleAutoCreate().
This also swaps the parameters of the method.
Thanks to Guus der Kinderen for suggesting this.
