Maven: Как управлять файлами, специфичными для платформы, такими как начальные скрипты (не библиотеки)

Question

У меня есть проект Java, состоящий из трех модулей

• проект-общий
• проект-а
• проект-б

Проект a и b использует -common в качестве зависимости.

Я использую простую конфигурацию сборки, чтобы поместить project-a, project-b и все зависимые библиотеки (пружины и т. Д.) В один архив.

Я также хочу предоставить начальные скрипты для разных платформ (windows32, windows64, linux32, linux64 и macosx). Например, я буду использовать для windows winrun4j и sh-scripts для linux.

Каков наилучший подход к управлению этими файлами (так как они не нуждаются в какой-либо компиляции и т. Д., Как нативные библиотеки)?

В настоящее время я поместил стартовые файлы для каждого проекта в его папку / main / resources / bin, в результате чего в сборке оказались все начальные скрипты для всех платформ.

Есть ли какая-то хитрость для того, чтобы переместить эти стартовые файлы в выделенные модули и каким-то образом управлять ими, чтобы иметь возможность создавать сборки "для конкретной платформы", включая только стартовые файлы для данной платформы?

Answer 1

Вы можете использовать профили активации и определения ОС:

<profiles>
    <profile>
        <activation>
            <os>
                <family>windows</family>
                <arch>x86</arch>
            </os>
        </activation>
        ....
    </profile>
</profiles>

---

Ресурсы:

• Введение в создание профилей
• Плагин Maven Enforcer - Требуется версия ОС

По той же теме:

• Maven: выяснение, работает ли в 32- или 64-разрядной JVM

Answer 2

Есть ли какая-то хитрость для того, чтобы переместить эти стартовые файлы в выделенные модули и каким-то образом управлять ими, чтобы иметь возможность создавать "специфичные для платформы" сборки, включая только стартовые файлы для данной платформы?

Если бы только сценарии запуска были специфичны для конкретной платформы (а не для кода), я бы не стал создавать сборки для конкретной платформы, а просто связал бы их все вместе.

Создание сборок, специфичных для платформы, сделает вашу сборку более сложной, трудной в обслуживании, более длительной в эксплуатации и все это без особой добавочной ценности для пользователей .Кажется, это того не стоит.

И это действительно не то, что делают большинство проектов, например:

Tomcat (простой случай)

С Tomcat вы получаетеи .sh и .bat версии сценариев в каталоге bin

pascal@laptop:~$ cd ~/opt/apache-tomcat-6.0.29/bin
pascal@laptop:~/opt/apache-tomcat-6.0.29/bin$  ls
bootstrap.jar       digest.bat        shutdown.sh           tool-wrapper.sh
catalina.bat        digest.sh         startup.bat           version.bat
catalina.sh         jsvc.tar.gz       startup.sh            version.sh
catalina-tasks.xml  setclasspath.bat  tomcat-juli.jar
commons-daemon.jar  setclasspath.sh   tomcat-native.tar.gz
cpappend.bat        shutdown.bat      tool-wrapper.bat

Сонар (сложный случай)

Сонар может быть лучшим примером, похоже на вашу ситуацию.При использовании Sonar каталог bin содержит подкаталоги, специфичные для платформы, со сценариями для каждой платформы:

pascal@laptop:~$ cd ~/opt/sonar-2.2/bin/
pascal@laptop:~/opt/sonar-2.2/bin$ ls
aix-ppc-32      hpux-parisc-64  linux-x86-64         solaris-x86-32
aix-ppc-64      linux-ia-64     macosx-universal-32  solaris-x86-64
hpux-ia-32      linux-ppc-32    macosx-universal-64  windows-x86-32
hpux-ia-64      linux-ppc-64    solaris-sparc-32
hpux-parisc-32  linux-x86-32    solaris-sparc-64
$ cd linux-x86-32/
$ ls
lib  sonar.sh  wrapper

Лично мне все равно, какие версии файлов запуска для конкретной платформы хранятся в одном архиве, aucontraire : мне не нужно искать и скачивать «правильный» архив, я могу распаковать его на нескольких платформах и т. д.

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