2013-11-17 2 views
0

Мой проект maven имеет зависимость. Я использую несколько сторонних классов. Я хотел бы автоматически переупаковать их в свою банку и исключить зависимость от pom.xml, хранящейся в файле jar.reackage dependencies и fix pom

Я проверил shade plugin и jarjar plugin. ни один из них не заменяет pom в изготовленной банке. в чем смысл включения бинарных файлов зависимостей, если эти зависимости все еще указаны в pom? как я должен правильно перепаковать зависимости?

+0

Если это третья сторона, о которой вы говорите, нет необходимости ее менять. –

+0

нет, я пошутил. я использую, например, StringUtils от commons-lang, у меня это как зависимость в моем пом. то я делаю 'package', и я хочу иметь этот класс в своей банке. но я не хочу, чтобы в моей банке больше не существовало зависимости от сообщества. – piotrek

ответ

1

Плагин Maven shade имеет функцию, в которой вы нуждаетесь. После запуска

mvn shade:shade 

Он генерирует файл с именем зависимостями восстановленной-pom.xml в папке ваших проектов, и этот файл не имеет зависимостей, которые уже размещены в банке.

Такое поведение настраивается с помощью следующих параметров тени-плагина:

+0

dependencyReducedPomLocation имеет ошибку, описанную в документации. кроме того, он создает файл где-то под каталогом сборки, а не внутри созданного jar – piotrek

+0

Maven является очень негибким для тонкой настройки. Я думаю, что это самая близкая возможность для вас. –

+0

@ YaroslavYermilov: Maven бесконечно гибкий для тонкой настройки, есть муравей и множество плагинов там, и в конце дня, если колесо еще не было изобретено, есть пользовательские плагины Maven, которые позволяют вам делать все, что вы можете сделать на Java. –

0

Вы можете использовать Maven-зависимость-плагин:

  <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-dependency-plugin</artifactId> 
       <version>2.8</version> 
       <executions> 
        <execution> 
         <id></id> 
         <phase>process-resources</phase> 
         <goals> 
          <goal>unpack</goal> 
         </goals> 
         <configuration> 
          <artifactItems> 
           <artifactItem> 
           <groupId>commons-lang</groupId> 
           <artifactId>commons-lang</artifactId> 
           <version>2.6</version> 
           </artifactItem> 
          </artifactItems> 
          <outputDirectory>${project.build.outputDirectory}</outputDirectory> 
          <includes>org\/apache\/commons\/lang\/StringUtils.class</includes> 
         </configuration> 
        </execution> 
       </plugin> 

И затем задайте область зависимостей сообщества-lang для Provi Ded:

     <dependency> 
          <groupId>commons-lang</groupId> 
          <artifactId>commons-lang</artifactId> 
          <version>2.6</version> 
          <scope>provided</scope> 
         </dependency> 

Обще-языки не будут осуществляться как переходная зависимость, ни быть включены в упаковке банки, но StringUtils будет включен в банке.

+1

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

+0

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

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