Если вы читали предыдущие пять блогов этой серии, вы будете знать, что я создавал приложение Spring, которое периодически запускается, чтобы проверять целую кучу журналов ошибок на наличие исключений, а затем отправлять вам результаты по электронной почте.
Написав код и тесты, и будучи достаточно уверенным, он сработает следующим и последним шагом — упаковать все это и развернуть на производственном компьютере. Фактические методы развертывания и упаковки будут зависеть от процессов и процедур вашей организации. Однако в этом примере я собираюсь выбрать самый простой способ создания и развертывания исполняемого файла JAR. Первый шаг был выполнен несколько недель назад, и это определяет наш вывод как файл JAR в файле Maven POM, который, как вы, вероятно, уже знаете, выполняется с использованием элемента упаковки:
|
1
|
<packaging>jar</packaging> |
Это нормально, если у вас есть JAR-файл, но в этом случае есть еще один шаг: сделать его исполняемым. Чтобы сделать исполняемый файл JAR, вам нужно добавить файл MANIFEST.MF и поместить его в каталог с именем META-INF . Файл манифеста — это файл, который описывает JAR-файл как для JVM, так и для читателей.
Как обычно, есть несколько способов сделать это, например, если вы хотите усложнить себе жизнь, вы можете вручную создать свой собственный файл и поместить его в каталог META-INF внутри src / main / resources проекта. каталог. С другой стороны, вы можете использовать плагин maven-jar и делать это автоматически. Для этого вам нужно добавить следующее в ваш файл POM.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
<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.MF , вы обнаружите что-то вроде этого:
|
1
2
3
4
5
6
7
8
|
Manifest-Version: 1.0Built-By: RogerBuild-Jdk: 1.7.0_09Class-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.jarCreated-By: Apache Maven 3.0.4Main-Class: com.captaindebug.errortrack.MainArchiver-Version: Plexus Archiver |
Последний шаг — собрать все файлы поддержки в один каталог, в данном случае — каталог lib , чтобы JVM могла найти их при запуске приложения. Опять же, есть два способа приблизиться к этому: легкий путь и трудный путь. Сложный путь включает в себя сбор вручную всех файлов JAR, как определено POM (как прямые, так и временные зависимости), и копирование их в выходной каталог. Самый простой способ — заставить maven-dependency-plugin сделать это за вас. Это включает добавление следующего к вашему файлу POM:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
<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> |
В этом случае вы используете цель copy-dependencies выполненную на этапе пакета, чтобы скопировать все зависимости проекта в каталог ${project.build.directory}/lib/ — обратите внимание, что последняя часть пути к каталогу, lib , соответствует настройке classpathPrefix из предыдущего шага.
Чтобы упростить жизнь, я также создал небольшой скрипт run: runme.sh :
|
1
2
3
4
|
#!/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 . Если вы хотите посмотреть другие блоги этой серии, загляните сюда …
- Отслеживание исключений приложений с помощью Spring
- Отслеживание исключений в Spring — часть 2 — шаблон делегата
- Отчеты об отслеживании ошибок — часть 3 — стратегия и пакет
- Отслеживание исключений — часть 4 — отправитель почты Spring
- Отслеживание исключений — часть 5 — планирование с помощью Spring
| Ссылка: | Отслеживание исключений — часть 6 — Создание исполняемого фляги от нашего партнера по JCG Роджера Хьюза в блоге Captain Debug’s Blog . |