Não é possível encontrar a class principal no arquivo compilado com Ant

Eu compilar e executar o meu programa no Eclipse e tudo funciona bem, mas quando eu empacotá-lo com Ant e executá-lo, recebo este erro:

Exception in thread "main" java.lang.NoClassDefFoundError: org/supercsv/io/ICsvB eanReader Caused by: java.lang.ClassNotFoundException: org.supercsv.io.ICsvBeanReader at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Could not find the main class: jab.jm.main.Test. Program will exit. 

Observe que este é um erro de tempo de execução e não um erro do compilador com o Ant.

Eu construí este projeto no passado com 0 problemas e agora de repente atua em mim quando eu adicionar um segundo pacote à minha pasta lib ?

Aqui está o arquivo de construção para referência:

    Builds client files into .jar                     <!--  -->                            

Obrigado antecipadamente pela ajuda!

EDITAR:

Aqui está o que a construção para a minha class principal parece (este não é o arquivo real, mas é isso que eu baseei o meu). A construção é muito estranha para um programa java e pode estar dando alguns problemas a Ant. Alguma recomendação sobre como reconstruir isso? Eu tenho um monte de erros ao tentar separar isso em várias partes. Eu nunca vi uma construção como essa antes (sim, eu entendo como funciona (e funciona quando compilada), mas o Ant pode não gostar).

 import java.io.FileReader; import java.io.IOException; import org.supercsv.cellprocessor.Optional; import org.supercsv.cellprocessor.ParseDate; import org.supercsv.cellprocessor.ParseInt; import org.supercsv.cellprocessor.constraint.StrMinMax; import org.supercsv.cellprocessor.constraint.Unique; import org.supercsv.cellprocessor.ift.CellProcessor; import org.supercsv.io.CsvBeanReader; import org.supercsv.io.ICsvBeanReader; import org.supercsv.prefs.CsvPreference; class ReadingObjects { static final CellProcessor[] userProcessors = new CellProcessor[] { new Unique(new StrMinMax(5, 20)), new StrMinMax(8, 35), new ParseDate("dd/MM/yyyy"), new Optional(new ParseInt()), null }; public static void main(String[] args) throws Exception { ICsvBeanReader inFile = new CsvBeanReader(new FileReader("foo.csv"), CsvPreference.EXCEL_PREFERENCE); try { final String[] header = inFile.getCSVHeader(true); UserBean user; while( (user = inFile.read(UserBean.class, header, userProcessors)) != null) { System.out.println(user.getZip()); } } finally { inFile.close(); } } } public class UserBean { String username, password, town; Date date; int zip; public Date getDate() { return date; } public String getPassword() { return password; } public String getTown() { return town; } public String getUsername() { return username; } public int getZip() { return zip; } public void setDate(final Date date) { this.date = date; } public void setPassword(final String password) { this.password = password; } public void setTown(final String town) { this.town = town; } public void setUsername(final String username) { this.username = username; } public void setZip(final int zip) { this.zip = zip; } } 

Observe como o nome da class é, na verdade, UserBean e contém uma class não pública chamada ReadingObjects dentro dele que contém o método main.

Parece que seu classpath de runtime está sem o jar contendo a class org.supercsv.io.ICsvBeanReader .

A pegadinha é que você não pode definir o caminho de class a partir da linha de comando ao chamar um jar executável. Você precisa configurá-lo no manifesto da seguinte maneira:

                    

Essa abordagem permitirá que você execute o jar da seguinte maneira:

 java -jar CC.jar 

Sem a input de manifesto extra, você deve executar o jar da seguinte maneira:

 java -cp CC.jar:CC-DSTAMPVALUE.jar jab.jm.main.Test 

Nota

Somente o CC.jar é executável e precisa do manifesto especial. Usar esse padrão significa que futuros jars adicionais, colocados no diretório lib, serão incluídos automaticamente no caminho de class de tempo de execução. (Útil para dependencies de software livre como log4j)

Obviamente, ao executar o CC.jar, você receberá um erro semelhante se os arquivos jar não estiverem presentes 🙂

Você tentou especificar explicitamente o caminho de class ao executar o jar, para garantir que a nova biblioteca esteja nele?

Talvez a biblioteca 1 esteja presente no caminho de class padrão, portanto, seu projeto foi executado corretamente até você include a biblioteca 2, que não estava presente. Ao executar dentro do Eclipse, o IDE pode estar automaticamente adicionando a biblioteca 2 ao classpath para você. Você pode verificar o caminho de class na Configuração de Execução do seu projeto no Eclipse e verificar se está incluindo tudo lá quando não estiver em execução por meio do IDE.

Isso pode estar acontecendo devido à localização dos arquivos de class gerados. isto é, quando você constrói um eclipse direto, ele gera os arquivos de class no local que é especificado como a pasta de saída para ex: bin e, durante a execução, ele examina esse local para os arquivos de class.

Portanto, verifique se sua formiga está gerando os arquivos de class no mesmo local da pasta de saída mencionada na configuração do BuildPath. Se não alterar o local da pasta de saída para o local onde sua formiga está gerando os arquivos de class .