Forma limpia de combinar múltiples frascos? Preferiblemente usando Ant

La respuesta de Vladimir es correcta, pero siento que lo que sugiere implica volver a empaquetar todos los frascos en una salida grande.tarro, que luego se alimenta a la tarea Tarro Hormiga como un solo <zipfileset> o algo así. Este enfoque en dos etapas es innecesario. No estoy seguro de si esto está conectado con la versión Ant, pero tengo Ant 1.7.1, y su tarea <jar> entiende <zipgroupfileset>, lo que permite alimentar todos los contenidos de jars de terceros directamente.

<jar destfile="MyApplication.jar">
  <zipgroupfileset dir="lib" includes="*.jar" /> 
  <!-- other options -->
  <manifest>
    <attribute name="Main-Class" value="Main.MainClass" />
  </manifest>
</jar>

Puedes echar un vistazo a jarjar:

Http://code.google.com/p/jarjar /

Intenta extraer tus JARS a un directorio de marshalling primero:

<target name="combine-jars">
    <mkdir dir="${marshall.dir}"/>
    <unzip dest="${marshall.dir}">
        <fileset dir="${external.jar.dir}">
            <include name="**/*.jar"/>
        </fileset>
    </unzip>
    <jar destfile="${combined.jar}" basedir="${marshall.dir"}>
    <delete dir="${marshall.dir}"/>
</target>

Donde ${marshall.dir} es un directorio temporal, ${external.jar.dir} es donde guardas el JAR, y ${combined.jar} es el JAR objetivo.

Si utilizas maven, ¿por qué no lo harías ? :) Solo tiene que utilizar el maven-sombra-plugin, funciona como un encanto !

  <project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>1.5</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <mainClass>com.YOUR_COMPANY.YOUR_MAIN_CLASS</mainClass>
                </transformer>
              </transformers>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Esta es mi solución:

<target name="-post-jar">
    <echo>Packaging ${application.title} into a single JAR</echo>

    <jar destfile="${basedir}${file.separator}${dist.dir}${file.separator}_${ant.project.name}_.jar">
        <zipgroupfileset dir="${basedir}${file.separator}${dist.dir}" includes="${ant.project.name}.jar"/>
        <zipgroupfileset dir="${basedir}${file.separator}${dist.dir}${file.separator}lib" includes="*.jar"/>
        <manifest>
            <attribute name="Main-Class" value="${main.class}"/>
        </manifest>
    </jar>
</target>

¿Ha considerado usar Maven o algún otro sistema que administre sus dependencias automáticamente? Entonces no necesitará especificar dónde se encuentra cada biblioteca, cuáles son sus nombres y qué dependencias transitivas tienen sus dependencias directas. Solo se indicaría en un solo lugar cuáles son la dependencia y su versión, y el sistema se encargaría de descargar las bibliotecas, configurar el classpath y construir el proyecto.

La pregunta está bien contestada. Quería mencionar una herramienta que me parece útil-One-Jar. One-Jar maneja los recursos de manera más limpia (manteniendo todos ellos). Esto es más útil si el código necesita procesar archivos de MANIFIESTO.

XML de ejemplo copiado del sitio web..

<import file="one-jar-ant-task.xml"/>   

    <target name="hello" depends="init">
        <!-- Build lib.jar -->   
        <javac destdir="${classes.dir}/lib">
            <src path="${lib.dir}" />
        </javac>
        <jar destfile="${build.dir}/lib.jar" >
            <fileset dir="${classes.dir}/lib"/>
        </jar>   
        <!-- Build classes for main.jar -->   
        <javac destdir="${classes.dir}/src">
            <src path="${src.dir}" />
            <classpath path="${build.dir}/lib.jar"/>   
        </javac>
        <!-- Construct the One-JAR file -->   
        <one-jar destfile="hello.jar" manifest="hello.mf">
            <main>
                <!-- Construct main.jar from classes and source code -->
                <fileset dir="${classes.dir}/src"/>
            </main>
            <lib>
                <fileset file="${build.dir}/lib.jar" />
            </lib>
        </one-jar>
        <echo>
          Now you can run the Hello One-JAR example using 
          $ java -jar hello.jar
        </echo>   

    </target>

Si está construyendo con ant (estoy usando ant de eclipse), puede agregar los archivos jar adicionales diciéndole a ant que los agregue... No necesariamente el mejor método si tiene un proyecto mantenido por varias personas, pero funciona para un proyecto de persona y es fácil.

Por ejemplo mi objetivo que estaba construyendo el.el archivo jar era:

<jar destfile="${plugin.jar}" basedir="${plugin.build.dir}">
    <manifest>
        <attribute name="Author" value="ntg"/>
        ................................
        <attribute name="Plugin-Version" value="${version.entry.commit.revision}"/>
    </manifest>
</jar>

Acabo de añadir una línea para hacerlo:

<jar ....">
    <zipgroupfileset dir="${external-lib-dir}" includes="*.jar"/>
    <manifest>
        ................................
    </manifest>
</jar>

Donde

<property name="external-lib-dir" value="C:\...\eclipseWorkspace\Filter\external\...\lib" />

Era el dir con las jarras externas. Y eso es todo... Puede agregar múltiples etiquetas zipgroupfileset también.

Bueno, no estoy tan metido en la programación, pero algo más simple funcionó para mí...si la pregunta significaba - la combinación de archivos jar en uno. Por supuesto, esto es manual, solución sucia. Acabo de desentrañar todos los alquitranes...y luego..creado un nuevo archivo tar, añadiendo todos los directorios formados por untarring-in al nuevo archivo tar. funcionó.

Maven u otras herramientas de compilación no pueden "administrar" la resolución de varias versiones de archivos de clase. De hecho, Maven causa estos problemas en primer lugar, a través de la inclusión transitiva de todos los archivos jar posteriores que no son explícitamente requeridos por un proyecto.

Supongamos que en algún lugar del cierre transitivo de un proyecto (todas las bibliotecas y módulos requeridos por el proyecto, y todos sus proyectos dependientes, recursivamente) hay dos versiones de un archivo de clase. ¿Cómo podría Maven posiblemente ¿sabes cuál es la 'correcta'? ¿cuál fue la intención del programador?

No puede porque esta información se perdió cuando las dependencias explícitas se desecharon en favor de las transitivas (para guardar la escritura XML).