Зависимость Maven POM с добавленным токеном на основе профиля

У нас есть POM для нашего основного проекта. Я бы сказал, что внутри определено от 10 до 15 профилей. Зависимости являются общими и, вероятно, насчитывают около 20 или около того.

У нас есть (по крайней мере) одна зависимость, где ее версия зависит от того, предназначен ли профиль для тестирования или производства. Производственные развертывания занимают:

<version>1.0.3.RELEASE</version>

как версия зависимости, тогда как развертывание dev и staging занимает

<version>1.0.3.STAGING</version>

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

Я читал о токенизации и пытался объявить общую зависимость следующим образом:

    <dependency>
        <groupId>org.groupId</groupId>
        <artifactId>lib-artifactId</artifactId>
        <version>1.0.3.${lib-artifactId.version}</version>
    </dependency>

а затем добавление

        <properties>
            <lib-artifactId.version>RELEASE</lib-artifactId.version>
        </properties>

к каждому профилю, где RELEASE изменен на STAGING, где это уместно.

Это не работает. Ошибка заключается в том, что он не может найти библиотеку с версией

1.0.3.${lib-artifactId.version}

Другими словами, это не замена токена.

Как бы я решил это?


maven pom.xml
person Marceau    schedule 06.08.2013    source источник
comment
Я уже использовал это решение (профили + свойство с разными значениями) в проекте, и оно отлично сработало. Вы уверены, что профили правильно активированы?   -  person Guillaume Darmont    schedule 06.08.2013
comment
Я почти уверен, что все профили работают так, как предполагалось и ожидалось. Одна вещь, которую я подумал, заключается в том, что, поскольку все мои профили находятся в pom.xml, maven может не иметь возможности разрешить токен, потому что он определяется много раз (один раз для каждого профиля).   -  person Marceau    schedule 06.08.2013

Ответы (3)


arrow_upward
0
arrow_downward

вместо определения токена в профиле, чтобы заменить его зависимостью в основном файле, вы можете попробовать:

сохраните зависимость в каждом профиле, как и раньше. Замените версию на токены ${lib-artifactId.release_version} или ${lib-artifactId.staging_version} в зависимости от ситуации и определите два токена в файле pom верхнего уровня.

person Graham Griffiths    schedule 06.08.2013
comment
Это было неплохо, но потребовалось бы добавить в pom больше информации, чем мне действительно хотелось бы. - person Marceau; 08.08.2013

arrow_upward
0
arrow_downward

В идеале вы должны использовать КЛАССИФИКАТОРЫ от maven

<dependency>
 <groupId>org.groupId</groupId>
 <artifactId>lib-artifactId</artifactId>
 <version>1.0.3</version>
 <classifier>${lib-artifactId.version}</classifier>
</dependency>

Это разрешится в 1.0.3-RELEASE

person Jaffar Ramay    schedule 06.08.2013
comment
Мне это нравится, но мне это не под силу. Тот факт, что он разрешается в - (дефис) RELEASE, был нарушителем условий сделки: это потребовало бы изменения имени упомянутой библиотеки (это имя только с точками, я думаю, вдохновленное выпусками Spring). - person Marceau; 08.08.2013

arrow_upward
0
arrow_downward

В итоге я сделал то, что, как мне казалось изначально, не сработало. Хотя он выдавал ошибки и заставлял Eclipse сканировать, он скомпилировался и запустился. Затем я также смог решить ошибку Eclipse, так что теперь у меня есть ситуация, которую я хочу.

Проблема с определением общей зависимости следующим образом:

<dependency>
    <groupId>org.groupId</groupId>
    <artifactId>lib-artifactId</artifactId>
    <version>1.0.3.${lib-artifactId.version}</version>
</dependency>

заключается в том, что Eclipse (или, по крайней мере, m2e) не может найти фактическую зависимость, когда вы просто кодируете, а не «внутри» определенного профиля. И поэтому выдает неприятные ошибки. Много красного. Конкретно:

ArtifactDescriptorException: Failed to read artifact descriptor org.groupId:lib-artifactId:jar:1.0.3.${lib-artifactId.version}: ArtifactResolutionException: Failure to transfer org.groupId:lib-artifactId:jar:1.0.3.${lib-artifactId.version} from http://xxx.xxx.xxx was cached in the local repository, resolution will not be reattempted until the update interval of xxx has elapsed or updates are forced. Original error: Could not transfer artifact org.groupId:lib-artifactId:jar:1.0.3.${lib-artifactId.version} from/to xxx (http://xxx.xxx.xxx): IllegalArgumentException

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

<lib-artifactId.version>RELEASE</lib-artifactId.version>

в раздел вверху, и все было в порядке.

person Marceau    schedule 08.08.2013