LINUX.ORG.RU

[Java] Грамотно собрать jar файл

 


0

0

Скажем если есть проект на яве, который использует сторонние библиотеки, из проекта надо собрать jar файл. Если это делать через eclipse то там все довольно просто, export->JAR File, но на выходе получается файл без сторонних библиотек.
Я пробовал потом вручную открыть jar файл и прописать Class-Path для библиотек, все работает. Но это какое то не красивое решение, придется каждый раз таскать за собой все эти библиотеки. А скажем если у юзера какая то часть либ уже стоит в системе нафига ему еще такие же?
Что делать в такой ситуации?
Была еще идея упаковать все сторонние либы в этот же jar файл, но не нашел как это сделать автоматический, но наверное можно и вручную их насувать.


>А скажем если у юзера какая то часть либ уже стоит
не стоит на это рассчитывать. Считай что у пользователя голый JRE

Была еще идея упаковать все сторонние либы в этот же jar файл, но не нашел как это сделать автоматический, но наверное можно и вручную их насувать.


путь правильный.
google:maven

Еще вариант: сделать дистрибутив архивом, в котором будет джарка приложения, джарки либ и bat/sh скрипт для запуска приложения. Этот вариант предпочтительнее всего, имхо.
Тоже делается мавеном. Плагин assembly

JFreeM ★★★☆
()

А скажем если у юзера какая то часть либ уже стоит в системе нафига ему еще такие же?


Ну в этом плана жаба тяжелый случай. Вообще, на самом деле жабу рассчитывали на то, что джарники скачиваются из Сети, т.е. classpath должен состоять не из C:\lib\apache.jar, а из http://apache.org/apache.jar «Компьютер - это Сеть»©Sun
А сейчас действительно, каждая прога на жабе имеет подкаталог lib\ с кучей сторонних джарников, некоторые вдобавок еще jre\ в дистриб суют

Karapuz ★★★★★
()
Ответ на: комментарий от JFreeM

Еще вариант: сделать дистрибутив архивом, в котором будет джарка приложения, джарки либ и bat/sh скрипт для запуска приложения. Этот вариант предпочтительнее всего, имхо.

+1. Просто и работает.

Legioner ★★★★★
()

Вообще куча jar-ников это для java проекта приложения это нормально.
Если по быстрому хочется и не думая, то распакуй все jar файлы и запакуй в один. Можно Main-Class в манифест прописать, тогда запуск будет java -jar program.jar

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

Так же можно запихнуть всё по разным папкам, а запускаемым сделать один пустой jar файл с манифестом в котором прописан Class-Path на локальные jar файлы и Main-Class, тогда запуск тоже будет java -jar fake.jar

А скажем если у юзера какая то часть либ уже стоит в системе нафига ему еще такие же?


Такого практически не бывает.
По энтерпрайзному, вообще в дистрибутив запихнуть java RE и запускать как угодно через sh/bat/exe.

vtVitus ★★★★★
()
Ответ на: комментарий от maxcom

Потихоньку разобрался с maven, оказалась очень удобная штука, правда сложная убил целый день что бы разобрать с assembly-plugin.

n4ela
() автор топика
Ответ на: комментарий от aydar

Да, проще. Если проект небольшой, с незамысловатой структурой, используются тривиальные (в плане сборки) библиотеки.

slyjoeh ★★★
()
Ответ на: комментарий от n4ela

Зря ты с assembly-plugin возился, он древний и неудобный. Лучше maven-shade-plugin. Вот рабочий пример, просто добавляешь в build/plugins и вуаля:

      <plugin>
        <artifactId>maven-shade-plugin</artifactId>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <finalName>${project.artifactId}</finalName>
                <transformers>
                <transformer
                  implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <mainClass>demo.App</mainClass>
                </transformer>
              </transformers>
            </configuration>
          </execution>
        </executions>
      </plugin>

dizza ★★★★★
()
Ответ на: комментарий от dizza

гм, я .jar собираю с использованием maven-bundle-plugin :-)

      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Export-Package>su.msk.jet.tikaserver.*</Export-Package>
            <Embed-Dependency>
                !jersey-server;scope=compile;inline=META-INF/services/**|au/**|javax/**|org/**|com/**|Resources/**|font_metrics.properties|repackage/**|schema*/**,
                jersey-server;scope=compile;inline=com/** |META-INF/services/com.sun*|META-INF/services/javax.ws.rs.ext.RuntimeDelegate
            </Embed-Dependency>
            <Embed-Transitive>true</Embed-Transitive>
            <Bundle-DocURL>${project.url}</Bundle-DocURL>
                    <Main-Class>su.msk.jet.tikaserver.TikaServerCli</Main-Class>
          </instructions>
        </configuration>
      </plugin>

maxcom ★★★★★
()

>Что делать в такой ситуации?

ant'ом собирать и прописать все нужные зависимости.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

ant убог, уныл, забыт и нафиг никому не нужен.

Зря ты с assembly-plugin возился, он древний и неудобный. Лучше maven-shade-plugin. Вот рабочий пример, просто добавляешь в build/plugins и вуаля:


спасибо за наводку, не знал.

JFreeM ★★★☆
()

Когда понадобилось нечто подобное, быстро нагуглили плагин к Eclipse под названием FatJar. Ну и антом собрали, да.

undertaker ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.