Лучший подход к настройке внешней зависимости в Maven - PullRequest
Новая
       3

Лучший подход к настройке внешней зависимости в Maven

2 голосов
/ 17 февраля 2012

Я надеюсь, что объясню это как можно точнее, и я хочу знать, правильно ли я настроил зависимости maven или есть ли лучший способ сделать это.

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

Я разрабатываю свои веб-приложения против Jetty в своей локальной разработке. Итак, чтобы веб-приложения работали локально, я настроил зависимости следующим образом: - 

<dependencies>
    <!-- Configuring external jar dependency -->
    <dependency>
        <groupId>com.test.app</groupId>
        <artifactId>app-jar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${env.EXTERNAL_JAR}</systemPath>
    </dependency>

    ...
</dependencies>

<build>
    <plugins>
        <!-- Configuring Jetty -->
        <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <version>6.1.26</version>
            <configuration>
                <contextPath>/${project.parent.artifactId}</contextPath>
                <jettyEnvXml>${env.JETTY_ENV_XML}</jettyEnvXml>
                <scanIntervalSeconds>1</scanIntervalSeconds>
                <connectors>
                    <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                        <port>7777</port>
                    </connector>
                </connectors>
                <webAppConfig>
                    <extraClasspath>${env.EXTERNAL_JAR}</extraClasspath>
                </webAppConfig>
            </configuration>
        </plugin>

        ...
    </plugins>
</build>

В этом подходе я устанавливаю переменную окружения, которая указывает на внешний путь jar, и ссылаюсь на нее в моем файле pom.xml как ${env.EXTERNAL_JAR}.

После некоторого чтения кажется, что использование "системной" области видимости считается плохой практикой. Итак, я установил этот внешний jar-файл в Nexus и изменил область действия на «предоставлено»: - 

<dependency>
    <groupId>com.test.app</groupId>
    <artifactId>app-jar</artifactId>
    <version>1.0</version>
    <scope>provided</scope>
</dependency>

Это позволяет мне правильно скомпилировать проект, но я не уверен, могу ли я вообще полностью избавиться от переменной окружения "EXTERNAL_JAR", потому что она все еще необходима для правильной работы среды выполнения Jetty. Я предпочитаю использовать «предоставленную» область видимости, это немного утомительно и требует дополнительной работы, потому что теперь мне нужно помнить, чтобы обновить jar в Nexus, когда он был изменен, и мне все еще нужно обновить jar, расположенный по пути, указанному переменной среды.

Есть ли способ для меня, чтобы открыть JAR-файл для внешнего баннера через зависимости maven, но при этом не быть упакованным в проект при создании файла war?

Что вы посоветуете по этому поводу? Должен ли я просто придерживаться «системной» области видимости, чтобы мне просто нужно было обновить банку в одном месте, или я должен использовать «предоставленную» область видимости? Или есть ли лучший способ сделать это?

Большое спасибо.

Ответы [ 3 ]

3 голосов
/ 18 февраля 2012

Вы должны иметь возможность добавлять зависимости в плагин Jetty. И тогда у меня есть предоставленная область для самого проекта.

http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin

как в 

<project>
... 
      <plugin> 
        <groupId>org.mortbay.jetty</groupId> 
        <artifactId>maven-jetty-plugin</artifactId> 
        <configuration> 
          <systemProperties> 
            <systemProperty> 
              <name>logback.configurationFile</name> 
              <value>./src/etc/logback.xml</value> 
            </systemProperty> 
          </systemProperties> 
        </configuration> 
        <dependencies>
          <dependency> 
            <groupId>ch.qos.logback</groupId> 
            <artifactId>logback-classic</artifactId> 
            <version>0.9.15</version> 
          </dependency> 
        </dependencies> 
      </plugin>
...
<project>
1 голос
/ 17 февраля 2012

Лучше всего настроить внешний репозиторий с вашей зависимостью и добавить его в pom. 

<repositories>
    <repository>
        <id>my-repo</id>
        <name>my-repo</name>
        <url>http://your.repo.url</url>
    </repository>
</repositories>

, а затем вы можете добавить свою зависимость как 

<dependency>
    <groupId>com.test.app</groupId>
    <artifactId>app-jar</artifactId>
    <version>1.0</version>
</dependency>
0 голосов
/ 20 февраля 2012

Я одобряю при условии. Предоставленное средство - загрузите зависимость на время компиляции, но я ожидаю увидеть ее в classpath на сервере приложений.

Я не осознавал, что вы заботитесь только о вашей локальной разработке, поэтому было бы полезно следующее, если вы запускаете Jetty на внешнем сервере:

Maven позволит вам развернуть файл на сервере с помощью плагина Wagon. Таким образом, частью вашего процесса сборки может быть вставка правильного файла .jar в ваш сервер Jetty. Таким образом, вам не придется делать это вручную. Я бы предпочел, чтобы это решение запускало локальный репозиторий Maven на сервере Jetty в соответствии с предложением @ Paul.

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

Неправильно изменять содержимое .jar и сохранять те же координаты Maven. Так что этот «умный» подход в любом случае не сработает.

...