Test build failure


I have a build failure with Smack as shown below.

I did a “svn up” before the build.

Any ideas?

Note that the class in question, Socks5PacketUtils, is in the test-unit directory. Also note that the same project in Eclipse Indigo has not issues.

I also tried an “ant clean”.



$ date; svn up

Fri 2 Dec 2011 11:55:21 CET

At revision 12901.

$ ant test

Buildfile: /smack_svn_workspace/smack/build/build.xml



[javac] Compiling 64 source files to /smack_svn_workspace/smack/target/classes-test

[javac] /smack_svn_workspace/smack/test/org/jivesoftware/smackx/bytestreams/socks5/Sock s5ByteStreamTest.java:37: cannot find symbol

[javac] symbol : class Socks5PacketUtils

[javac] location: package org.jivesoftware.smackx.bytestreams.socks5

[javac] import org.jivesoftware.smackx.bytestreams.socks5.Socks5PacketUtils;

[javac] ^

[javac] smack_svn_workspace/smack/test/org/jivesoftware/smackx/bytestreams/socks5/Socks 5ByteStreamTest.java:81: cannot find symbol

[javac] symbol : variable Socks5PacketUtils

[javac] location: class org.jivesoftware.smackx.bytestreams.socks5.Socks5ByteStreamTest

[javac] Bytestream bytestreamInitiation = Socks5PacketUtils.createBytestreamInitiation(

[javac] ^

[javac] Note: /smack_svn_workspace/smack/test/org/jivesoftware/smack/PrivacyClient.java uses unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.

[javac] 2 errors


/smack_svn_workspace/smack/build/build.xml:146: Compile failed; see the compiler error output for details.

Total time: 3 seconds

$ ant -version

Apache Ant™ version 1.8.2 compiled on December 20 2010

uname -a

Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

$ java -version

java version “1.6.0_29”

Java™ SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)

Java HotSpot™ 64-Bit Server VM (build 20.4-b02-402, mixed mode)

Some pointers/clues:

  • test-unit does not appear in the build.xml, so it is not clear how the code in that directory could be on the classpath for an ant build.

  • test-unit does appear in Smack.iml and SmackUnitTest.iml. The file extension “.iml” could be a configuration file for IntelliJ.

The above two clues might mean that the tests work in IntelliJ because of the .iml files, but don’t actually work with an ant build. If Smack is typically maintained with IntelliJ, and there is no manual test of the ant build, it could be that this has not come to anyone’s attention before.

More oddities.

The classpath for the compile-test section is defined as:


$f junit.jar



$ f xmlunit.jar


Summary, xmlunit.jar is not in the location that the build.xml thinks it should be.

So, having figured that out, I hacked the compile-test target like this:







I do NOT think that this is how this should be fixed. I can report, though, that the mock jars do not seem to appear in the build.xml in any other place, so I don’t see how the build.xml could be used to build the test-unit classes that the test classes seem to depend on.

I suspect, then, that the ant build actually doesn’t work as expected, or has not been maintained or …?

Also, to get the tests to actually run via ant, I had to add this to the classpath in the test target:

You are correct, the test cases do not run properly via ant.

Unfortunately it is something that I have not had the time to investigate and fix.


Thanks for following up. In a different thread you invited me to submit a patch for a different issue that I had discovered. It was in the course of preparing to work on that patch that I realised that the build didn’t work.

You can understand that there are some basic steps that someone submitting a patch might want to go through, amongst which is ensuring that the patch doesn’t break anything. The best way to make sure nothing is broken is to make sure the build runs the same before and after. But it doesn’t run at all.

Since I am not actually paying for this code, I am obviously not in a position to require anything in particular. Even so, you might want to reflect on whether the lack of a working build inhibits others, like me, from contributing to the project.



Hi Nathan,

can you provide a patch that would make the tests via ant possible? Robin is very careful in before adding changes which is a pretty good idea considering that Openfire and Spark depend on Smack as well as others.

The development infrastructure (and I would consider junit as part of that) of any project needs a concentrated effort which is time consuming. It also depends on the willingness of the guy who is doing the change to keep fixing all stuff until it is stable again.

The whole igniterealtime project misses these player. Are you going to be one of the needed core developers?


Hi Walter

I did provide the details of the hack required to make the build run, but that was a hack.

I think that the root of the problem here is actually a dependency from the test code on the unit test code; specifically the use of the Socks5PacketUtils from the unit test code in the test code. Apart from that dependency, the tests and unit tests are decoupled.

If they had remained decoupled then I would not have had to hack the classpath to get the compilation to work. I probably would have still needed to adjust the classpath in the build.xml for the test run part though.

The fact that this has not been spotted before would seem to imply that there is no continuous integration (CI) build for Smack, or at least not one that uses the ant build.

So, I can submit patches (indeed, that was what started me down the path of trying to build at all), but I would need to know more about your development environment to make sure that what I might suggest in the patches makes sense.



Thanks for the information Nathan, it will make it easier to try and fix the problem now that you have already diagnosed its cause.

You are correct that there is no proper CI being done, there is a build, but the tests are omitted for the reason you have already discovered. I use eclipse for development and confirm the test cases run there before doing an actual release.

Don’t let this stop you from contributing a patch, it is merely a bump in the road, one of many that I will try and fix in due time. Unfortunately, time is my limiting factor.

Thanks for you insight



Thanks for following up. A few niggles to clear up below. Note that I am not a fan of Ant (I prefer Maven) so I am struggling a bit to make sense of the build.

  • We have java-xmlbuilder-0.3.jar and xmlunit.jar in a build/build directory and various other jars in the build directory. Is their a rationale for this? Do we need the build/build directory? A tidier alternative would be a build/test-libs directory and move all test jars to that.

  • I can’t see a target, test-unit say, that runs the unit tests. Just compile-test that compiles all of the test code. Is there a way in which the build is expected, in its current form, to run the unit tests?

  • The dependency on the unit test code from the test code would normally indicate that we need to create a test-util, say, library that both unit and functional tests are dependent on. It is clearly possible not to do that, but it would be tidier so that unit and functional tests are decoupled at the code level. Of course, a func-test target should be dependent on a putative unit-test target, but that is a run time dependency, as opposed to compile time.

It might be easier to have a conference call to talk about this, so feel free to send me a private message and we can liaise offline.



I am also a Maven user, hence the reason this issue you found wasn’t already fixed as well. I was converting the build to maven, in fact, but that kind of stalled due to more pressing issues some time ago. Hopefully I can pick it up again for a future major release.


If we both prefer Maven, then maybe my other questions about the Ant build are moot, as there doesn’t seem to be much point fixing the Ant build when it is the Maven build we actually want.

Perhaps we should have a call to see how I could best help here?