2014-01-30 4 views
1

У меня есть projectX, который производит как его артефакт TXT-файл. Это единственный артефакт, созданный проектом. Это хорошо работает. Нет проблем.Maven: как создать проект без размножающихся отпечатков?

Проблема в том, что проекты, зависящие от этого артефакта, тянут с собой все артефакты projectX, которые, очевидно, не имеют отношения к TXT-файлу, не имеют зависимостей. Для создания файла TXT fileX, конечно, имеется ряд зависимостей, но они не имеют отношения к нисходящим проектам.

Я знаю, что могу в каждом отдельном проекте, использующем этот файл TXT, исключать эти транзитивные зависимости. Это не то, что я хочу. Я бы хотел, чтобы они были остановлены в самом проектеX, так что мне не нужно объявлять такие исключения в каждом последующем проекте.

В моем ограниченном знании Maven я думаю, мне нужно будет посмотреть параметр scope зависимостей projectX. Я ищу тип области, который говорит: «эта зависимость требуется для компиляции и выполнения проектаX, но она не является транзитивной». Невозможно найти такой объем.

Как я могу решить эту проблему, не испортив нисходящие проекты? (Те, которые используют артефакт произведенный ProjectX)

EDIT1: Мой вопрос с «при условии» рамки, что ProjectX сделан таким образом, чтобы он на самом деле выполняет себя как часть процесса сборки. По общему признанию, это необычно, но это то, что создает TXT-файл, который является истинным результатом сборки. Другими словами: зависимости ProjectX должны быть доступны не только для компиляции проектаX, но также для исполнения проектаX, но они не должны распространяться.

EDIT2:

Как я выполняю сам ProjectX в рамках своего собственного процесса сборки:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>exec-maven-plugin</artifactId> 
    <version>1.2.1</version> 
    <executions> 
     <execution> 
      <id>build-txt-file</id> 
      <phase>prepare-package</phase> 
      <goals> 
       <goal>exec</goal> 
      </goals> 
      <configuration> 
       <executable>${java.home}/bin/java</executable> 
       <arguments> 
        <argument>-classpath</argument> 
        <!-- automatically creates the classpath using all project dependencies, also adding the project build directory --> 
        <classpath/> 
        <argument>...</argument> 
       </arguments> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

Если я объявляю DEPS ProjectX как provided то выше шаг не будет работать.

ответ

2

Похоже, что provided scope соответствует вашим требованиям. Цитирую из документации Maven вы связаны между собой:.

Это очень похоже на компиляции, но указывает, вы ожидаете JDK или контейнера, чтобы обеспечить зависимость во время выполнения [...] Эта область является доступна только на компиляция и путь класса тестов и не являются транзитивными.

(курсив мой)


EDIT (после осветления в комментариях и правок): Подведем итоги, кажется, артефакт в том смысле, Maven не является действительно файл TXT, по крайней мере, исключительно, и сборка фактически компилирует некоторые классы и запускает их в пределах сборка. А теперь вернемся к решению проблемы :).

Причина, по которой вы застряли, заключается в том, что вы, возможно, нарушаете соглашение Maven о том, что такое артефакт . В частности, зависимости вашего проекта ожидают, что ваш проект «TXT» - это что-то еще, и именно поэтому вы столкнулись с проблемами.

Я вижу два пути выхода из этого:

  • Как упоминалось в комментариях, вы можете написать плагин, который будет обрабатывать поколение TXT файлов.
  • Как быстро и грязные решения вы можете:
    1. Сплит свой проект на два: а «генератор» (который требует DEPS) и «держателем» (который только производит и хранит файл TXT).
    2. В вашем проекте «генератор» упакуйте код генератора и все его зависимости в «uberjar», используя assembly plugin (по-видимому, устарел) или shade plugin (см. «Примеры»). Постарайтесь указать основной класс.
    3. Запустите install, чтобы включить артефакт «генератор» в ваше репо.
    4. В вашем проекте «держатель» используйте dependency plugin, чтобы скопировать «генератор» JAR где-то в target.
    5. Наконец, в вашем проекте «держатель», используя exec-maven-plugin, выполните загруженный «генератор» JAR.

Обратите внимание, что второе решение в основном «плагин бедняка», так что если у вас есть больше сценариев, как, что в вашем строит, научиться писать Mojos бы, возможно, обеспечить лучшую отдачу в долгосрочной перспективе. Тем не менее, я надеюсь, что это решает вашу проблему.

+0

Да и нет. «предоставлено» в порядке с точки зрения того, что Maven фактически попытается извлечь эту зависимость из репозитория (вы могли бы подумать, что «предоставлено» означало именно то, что этого не делало!) и что зависимость не является транзитивной. Но тот факт, что деп не становится частью пути класса исполнения, не идет! Это не сработает! – peterh

+0

@ nolan6000: зачем вам это нужно во время выполнения (я предполагаю, поскольку нет пути к классу «исполнение» для моего знания) classpath, если артефакт ** только ** является TXT-файлом? Измените свой вопрос, чтобы включить эту информацию. –

+0

Я отредактировал вопрос. – peterh

0

Вы должны указать свои зависимости в «ProjectX» как optional. Таким образом, когда ваши другие проекты включают его, он не разрешается как транзитивная зависимость. :)

Сфера «предоставлена» использует семантику, которую она обеспечивает чем-то другим (например, контейнер JEE должен был обеспечить сервлет api).

+0

Wauw. Я должен признать, что это первый раз, когда я слышу о * дополнительных зависимостях *. Очень неловко. Поначалу кажется, что это именно то, что мне нужно. – peterh

Смежные вопросы