package com.sun.speech.freetts does not exist.

By: Kris Bravo

The short version is that you don't have the libraries in your classpath when you compile. But once you run the test in your own environment, you also need to make sure the following property is set:

-Dfreetts.voices=com.sun.speech.freetts.en.us.cmu_us_kal.KevinVoiceDirectory

The long version: You may have already resolved this issue, but just in case and for the sake of closure, here are some pointers.

First, the freetts libraries make copious and unruly use of classpaths built into the Manifest.mf files of the libraries. They all have relative paths hardcoded in them (!) which require their dependencies to all be located in specific locations.

So it sounds like two things went wrong in your environment. First, the libraries don't go in your jdk install, they go along with you application. Next, they must go in the same directory - it is not enough for them to all be on the classpath (breaks maven unit testing for example). Finally, you need to have the speech.properties file in your home directory or in your jdk install's lib. Otherwise you must set a system property according to the javadocs:

freetts.sourceforge.net/javadoc/com/sun/speech/freetts/VoiceManager.html

I've testing this by setting it via System.setProperty with success.

For anyone reading this and using maven, I strongly suggest using the dependency:unpack-dependencies goal (or unpack in your ant script as well) if you intend to deploy in a "normal" application (jar, war, ejb, etc): Here is what I am using.


<plugin>
  
<groupId>org.apache.maven.plugins</groupId>

  
<artifactId>maven-dependency-plugin</artifactId>

  
<executions>

  
<execution>

  
<id>unpack</id>

  
<phase>compile</phase>

  
<goals>

  
<goal>unpack-dependencies</goal>

  
</goals>

  
<configuration>

  
<outputDirectory>${project.build.directory}/classes</outputDirectory>

  
<includeScope>runtime</includeScope>

  
</configuration>

  
</execution>

  
</executions>

  
</plugin>

I spent a weekend trying to get this library to behave. Outside of the demo files, it does not reliably "just go". It takes some serious tweaking. I chose to unpack and consolidate the class files into my jar file to work around the built in classpath dependencies (even stripping the classpath directives out of the manifests didn't take).