Ant для Maven - несколько целей сборки

Ответ 1

Ваша первая мысль правильная. Разделите 2 части на 2 проекта.

Философия maven заключается в том, что каждый проект должен строить один и только артефакт (jar, war, whatever)

Возможно, вы могли бы взломать что-то вместе, так что у вас будет только один проект maven, создающий 2 atrifacts, но это будет взлом.

Вы можете вызвать ant из maven, поэтому, если вы действительно этого хотите, я предлагаю вам начать просмотр плагина maven ant. Идентификатор артефакта - это "maven-antrun-plugin"

Ответ 2

Вы можете сделать это с помощью профилей...

Если вы действительно хотели использовать два отдельных профиля и настроить плагин JAR для включения и исключения шаблонов имен классов и пакетов, вы можете легко сделать это, помещая что-то вроде этого в свой POM:

<profiles>
  <profile>
    <id>everything</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <configuration>
            <classifier>everything</classifier>
            <includes>
              <include>**/*</include>
            </includes>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>only-library</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <configuration>
            <classifier>only-library</classifier>
            <excludes>
              <exclude>**/Main*</exclude>
            </excludes>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

Кроме того: если это похоже на большую конфигурацию, поддержка polyglot Maven для Groovy POMs готова. Он значительно сократит количество строк.

Вы поместили бы это в конец своего pom.xml(с элементом проекта) и добавили два профиля. Первый профиль "все" действительно существует, чтобы продемонстрировать конфигурацию. Этот профиль "все" лишний, потому что он просто дублирует поведение выполнения JAR-плагина по умолчанию JAR. Второй профиль "only-library" исключает любой класс в любом пакете, который начинается с текста "Main". Чтобы вызвать эти профили:

mvn package -Peverything
mvn package -Ponly-library

Я тестировал это на примере приложения, которое поставляется с Глава 6 Maven по примеру, и при запуске любой из этих команд будет создан JAR файл в ${basedir}/target, который имеет классификатор. Поскольку цель JAR-плагина связана с фазой пакета в жизненном цикле по умолчанию maven, эти два профиля собираются изменить конфигурацию для этого плагина.

Или вы можете сделать это с помощью двух плагинов JAR...

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

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

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <executions>
          <execution>
            <id>only-library</id>
            <goals><goal>jar</goal></goals>
            <phase>package</phase>
            <configuration>
              <classifier>only-library</classifier>
              <excludes>
                <exclude>**/Main*</exclude>
              </excludes>
            </configuration>
          </execution>
          <execution>
            <id>everything</id>
            <goals><goal>jar</goal></goals>
            <phase>package</phase>
            <configuration>
              <classifier>everything</classifier>
              <includes>
                <include>**/*</include>
              </includes>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Если вы не говорите о включении другого набора классов в каждый артефакт, вы захотите использовать Maven Assemblies. Если вы хотите узнать подробности сборок, в конце этого ответа есть глава, указанная в Maven: The Complete Reference. Честно говоря, я не думаю, что эта конкретная глава является хорошей вводной ссылкой; на самом деле, у меня было множество сообщений, что эта глава почти нечитаема (и мы работаем над ее устранением). Если вы хотите использовать сборки, я бы рекомендовал документацию Maven Assembly Plugin. В левом навигационном меню вы увидите список дескрипторов сборки образца.

Отказ от ответственности: (Пожалуйста) не делайте этого. Если вы создаете два разностных JAR с двумя разными наборами классов, я настоятельно рекомендую вам разделить проект на два взаимозависимых модуля.

Пока вы можете сделать это с помощью профилей, вам будет проще разделить проект на два (фактически три). В долгосрочной перспективе будут проблемы, с которыми вы столкнетесь, поскольку ваши приложения масштабируются. Вы будете нести ответственность за определение этого списка ручных классов и пакетов, которые будут включены в каждый из ваших классифицированных JAR.

Минимальные накладные расходы - это простой родительский проект, который ссылается на два отдельных модуля. Если вы посмотрите на бесплатную книгу Maven по примерам, мы покажем, как сделать переход между одномодульным и многомодульным проектом. Главы 3-5 сосредоточены на проектах с одним модулем и Глава 6 показывает вам, как объединить эти компоненты одного модуля в более крупный многомодульный проект.

Для получения дополнительной информации:

Вы задаёте следующие темы: вот некоторые ссылки, которые будут содержать более подробную информацию для каждого:

Плагин Maven JAR: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html

Многомодульные проекты Maven: Глава 6 из Maven по примеру и Раздел 3.6.2 Maven: полный справочник.

Жизненный цикл Maven (jar обязателен для упаковки, если ваш пакет является "jar" ): Раздел 3.5.2 Maven по примеру "Основные понятия" и Глава 4 из Maven: полная ссылка

Maven Assemblies: во-первых, Maven Assembly Plugin site, затем Chapter 8 из Maven: полный справочник для некоторых тяжелых (почти слишком тяжелых) деталей.

Ответ 3

У вас есть 2 варианта:

• Profiles
• Ассембли

Если подмножество представляет собой только набор ресурсов, то я бы не стал отдельным модулем.

Если проект всегда зависит от подмножества, которое упаковано единым образом, то подмножество является хорошим кандидатом, чтобы стать module.

Если подмножество переупаковано в несколько разных "ароматов", я бы определял сборки для каждого "аромата" и квалифицировал имена артефактов с помощью "классификатора", см. координаты maven.

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