Я пытаюсь настроить структуру каталогов (и файлы проекта) для проектов, которые должны будут использовать общий набор Jar-файлов (и в некоторых случаях код, который просто импортируется в рабочий проект).
Например, предположим, что у меня есть общий проект с именем «common». Этот проект содержит общий код и jar-файлы, которые могут использоваться автономным Java-приложением или, в данном случае, динамическим веб-приложением.
Мой веб-проект (назовем его webapp1) импортирует исходный код из «общего», так что это не проблема. Причина, по которой я это делаю, заключается в том, что на данный момент мне действительно нечего создавать "общий" проект и компилировать его в jar, а затем ссылаться на него из webapp1, потому что webapp1 не будет собирать jar-файлы поставщика, поскольку все они должны находиться в WEB-INF / lib.
Так как я могу это сделать? Я думал о том, чтобы просто сделать WEB-INF символической ссылкой на другой каталог с моими банками в нем, но это не сработало бы для сред Windows. Но в основном я к этому стремлюсь. Вот изображение этого:
common \
src \
some.source.packages
lib \
HibernateLibs \
hibernate.jar
hibernate2.jar
ApacheCommonLibs \
common-string.jar \
etc.
webapp1
src \
local.source.packages
reference to common.source.packages above
WebContent \
WEB-INF \
lib \
This is where I'd like to place references to the libs in common
(only those I need for this web app)
Если у меня есть обычная ссылка на webapp1, этот вид работает, но в тот момент, когда я пытаюсь запустить свой webapp1 из IDE, эти библиотеки на самом деле не в нужном месте.
Обратите внимание, что системы сборки, такие как Maven и т. д., Более или менее отсутствуют, потому что моя компания разрешает только определенные библиотеки и версии этих библиотек (это боль, но это то, с чем мне приходится работать).
Спасибо за понимание этого. Я не зацикливаюсь на структуре проекта, но я хочу избежать создания нескольких проектов с одинаковыми JAR-файлами повсюду и синхронизировать их (не говоря уже о том, что проверка кода очень медленная).




Когда вы создаете веб-проект, нет необходимости добавлять свои библиотеки в папку WEB_INF.
Решения:
Вы можете установить свои библиотеки в локальный репозиторий maven на свой локальный компьютер. Таким образом, зависимости будут извлечены с вашего локального компьютера. Все очень просто:
mvn install:install-file -Dfile=[file_path] -DgroupId=[your group id] -DartifactId=[artifact id] -Dversion=[version] -Dpackaging=jar
Также вы можете использовать сервер Nexus или Jfrog artifactory для получения jar-файлов. Для вашей компании этот сервер будет Только. Так баночки будут доступен только для вашей компании.
По умолчанию плагин весенней загрузки упаковывает все зависимости проекта в исполняемый файл JAR со следующей структурой:
МАНИФЕСТ.MF отвечает за поиск файлов JAR. Весной у нас есть следующие ланчеры: JarLauncher, WarLauncher, и СвойстваLauncher. Их назначение - загрузка ресурсов. JarLauncher - это только в состоянии для поиска и загрузки классов внутри BOOT-INF и JAR внутри каталога lib. Но вы можете использовать Свойства для указания файлов jar вне проекта. Так что давай сделаем это! Прежде всего, вы должны использовать формат ZIP.
Maven:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
</configuration>
</plugin>
Gradle:
springBoot{
layout = "ZIP"
}
Тогда все просто. Теперь запустите веб приложение:
java -Dloader.path=lib,external-jar.jar -jar starter.jar
Теперь у нас есть папка без WEB_INF веб-приложения и все файлы jar зависимостей вне приложения. Ну наконец то у нас есть много проектов, которые используют те же библиотеки jar, что и вне проекта.
Спасибо grep и csmckelvey, я даже не подумал о настройке для этого локального репозитория maven. Я рассмотрю вашу рекомендацию подробнее и опробую эти подходы.
Не следует полагаться на Eclipse при создании пакета развертывания (файла .war). Используйте инструмент сборки, такой как Ant, Maven, Gradle, ...
Если у компании есть стандартный набор авторизованных библиотек, компания должна создать внутренний репозиторий Maven, содержащий эти библиотеки (например, используя Artifactory), и вы должны использовать Maven для получения библиотек, необходимых для вашего конкретного проекта, из репозитория что и для сборки пакета развертывания. Преимущество: Все библиотеки находятся в одном месте, а не в системе контроля версий.
Если вы не можете заставить компанию создать репозиторий, но у вас есть «общий» проект со всеми библиотеками, используйте Ant для сборки проекта и создания пакета развертывания. Преимущество: Сборка проекта воспроизводится как пакетная сборка.
Gradle - достойная альтернатива Maven и Ant.
Привет, Андреас, я не использую его для сборки развертываемого, просто для тестирования в среде IDE во время разработки. Когда все будет готово к развертыванию, я создаю файл .war и для этого могу скопировать любые jar-файлы, которые мне нужны. Спасибо.
@Russ «Я создаю файл .war и для этого могу копировать любые jar-файлы, которые мне нужны» Звучит как ручная операция, то есть не автоматическое воспроизводимое действие. Существуют инструменты сборки, которые делают сборки автоматическими, поэтому производственные сборки могут быть точно воспроизведены.
«моя компания разрешает только определенные библиотеки и версии этих библиотек» Это не означает, что вы не можете использовать maven или другие инструменты сборки - просто включайте только утвержденные зависимости.