Если вы прочитали предыдущие пять блогов этой серии, вы узнаете, что я создавал приложение Spring, которое периодически запускается, чтобы проверять целую кучу журналов ошибок на наличие исключений, а затем отправлять вам результаты по электронной почте.
Написав код и тесты, и будучи достаточно уверенным, он сработает следующим и последним шагом — упаковать все это и развернуть на производственном компьютере. Фактические методы развертывания и упаковки будут зависеть от процессов и процедур вашей организации. Однако в этом примере я собираюсь выбрать самый простой способ создания и развертывания исполняемого файла JAR. Первый шаг был выполнен несколько недель назад, и это определяет наш вывод как файл JAR в файле Maven POM, который, как вы, вероятно, уже знаете, выполняется с использованием элемента упаковки:
<packaging>jar</packaging>
Это нормально, если у вас есть JAR-файл, но в этом случае есть еще один шаг: сделать его исполняемым. Чтобы сделать исполняемый файл JAR, вам нужно добавить файл MANIFEST.MF и поместить его в каталог с именем META-INF.
Файл манифеста файл , который описывает файл JAR как для виртуальной машины Java и человека читателей.
Как обычно, есть несколько способов сделать это, например, если вы хотите усложнить себе жизнь, вы можете вручную создать свой собственный файл и поместить его в каталог META-INF внутри src / main / resources проекта. каталог. С другой стороны, вы можете использовать
плагин maven-jar и делать это автоматически. Для этого вам нужно добавить следующее в ваш файл POM.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.captaindebug.errortrack.Main</mainClass>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
Интересным моментом здесь является элемент конфигурации <archive> <manifest>. Он содержит три подэлемента:
- addClasspath: это означает, что плагин добавит classpath в файл MANIFEST.MF, чтобы JVM могла найти все файлы поддержки при запуске приложения.
- mainClass: сообщает плагину добавить атрибут Main-Class в файл MANIFEST.MF, чтобы JVM знала, где найти точку входа в приложение. В этом случае это com.captaindebug.errortrack.Main
- classpathPrefix: это действительно полезно. Это позволяет вам находить все jar поддержки в другом каталоге основной части приложения. В этом случае я выбрал очень простое и короткое имя lib.
Если вы запустите сборку, а затем откроете получившийся файл JAR, извлечете и изучите файл /META-INF/MANIFEST.MFfile, вы найдете что-то вроде этого:
Manifest-Version: 1.0 Built-By: Roger Build-Jdk: 1.7.0_09 Class-Path: lib/spring-context-3.2.7.RELEASE.jar lib/spring-aop-3.2.7.RELEASE.jar lib/aopalliance-1.0.jar lib/spring-beans-3.2.7.RELEASE.jar lib/spring-core-3.2.7.RELEASE.jar lib/spring-expression-3.2.7.RELEASE.jar lib/slf4j-api-1.6.6.jar lib/slf4j-log4j12-1.6.6.jar lib/log4j-1.2.16.jar lib/guava-13.0.1.jar lib/commons-lang3-3.1.jar lib/commons-logging-1.1.3.jar lib/spring-context-support-3.2.7.RELEASE.jar lib/spring-tx-3.2.7.RELEASE.jar lib/quartz-1.8.6.jar lib/mail-1.4.jar lib/activation-1.1.jar Created-By: Apache Maven 3.0.4 Main-Class: com.captaindebug.errortrack.Main Archiver-Version: Plexus Archiver
Последний шаг — собрать все файлы поддержки в один каталог, в данном случае — каталог lib, чтобы JVM могла найти их при запуске приложения. Опять же, есть два способа приблизиться к этому: легкий путь и трудный путь. Сложный путь состоит в том, чтобы вручную собрать все файлы JAR, как определено POM (как прямые, так и временные зависимости), и скопировать их в выходной каталог. Самый простой способ — заставить
подключаемый модуль maven-dependency-plugin сделать это за вас. Это включает добавление следующего к вашему файлу POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>
${project.build.directory}/lib/
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
В этом случае вы используете цель копирования-зависимостей, выполненную на этапе пакета, чтобы скопировать все зависимости проекта в каталог $ {project.build.directory} / lib / — обратите внимание, что последняя часть пути к каталогу,
lib , соответствует настройке classpathPrefix из предыдущего шага.
Чтобы упростить жизнь, я также создал небольшой скрипт run: runme.sh:
#!/bin/bash echo Running Error Tracking... java -jar error-track-1.0-SNAPSHOT.jar com.captaindebug.errortrack.Main
И это все. Приложение почти готово. Я скопировал его на свою сборочную машину, где он теперь отслеживает примеры приложений и сборки Captain Debug Github.
Я мог бы и даже могу добавить еще несколько функций в приложение. Есть несколько грубых краев, которые нужно выбить из кода: например, лучше ли запускать его как отдельное приложение, или лучше было бы превратить его в веб-приложение? Кроме того, не будет ли хорошей идеей обеспечить, чтобы одни и те же ошибки не сообщались дважды?
Возможно, я скоро найду что-нибудь, или я поговорю о чем-то другом; так много о блоге так мало времени …
Код для этого блога доступен на Github по адресу:
https://github.com/roghughe/captaindebug/tree/master/error-track . Если вы хотите посмотреть другие блоги этой серии, загляните сюда …