Плагин релиза Maven завершается неудачно: исходные артефакты развертываются дважды - PullRequest
57 голосов
/ 23 ноября 2010

Мы используем плагин Maven Release для Hudson и пытаемся автоматизировать процесс выпуска. Релиз: подготовить, работает отлично. Когда мы пытаемся сделать выпуск: выполнить, он терпит неудачу, потому что пытается дважды загрузить исходный артефакт в хранилище.

Вещи, которые я пробовал,

  1. удаление профиля, включающего плагин maven source, из супер-помпа (не работает)
  2. указание целей для hudson для выпуска в виде -P! Что я думал, что исключит плагин исходного кода от выполнения. (не работает).
  3. попытался указать фазу плагина для некоторой несуществующей фазы в супер-помпе. (Не работает)
  4. попытался указать конфигурацию плагина для forReleaseProfile как false. (угадайте что ?? тоже не сработало)

Эта ошибка все еще выплевывается.

[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xx.xx.xx:8081/nexus/content/repositories/releases//com/yyy/xxx/hhh/hhh-hhh/1.9.40/hhh-hhh-1.9.40-sources.jar
[INFO] 57K uploaded  (xxx-xxx-1.9.40-sources.jar)
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases//com/xxx/xxxx/xxx/xxx-xxx/1.9.40/xxx-xxx-1.9.40-sources.jar
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Error deploying artifact: Authorization failed: Access denied to: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases/com/xxx/xxx/xxx/xxx-config/1.9.40/xxx-xxx-1.9.40-sources.jar

Любая помощь в этом отношении будет очень признательна.

Ответы [ 9 ]

66 голосов
/ 29 мая 2012

Попробуйте запустить mvn -Prelease-profile help:effective-pom.Вы обнаружите, что у вас есть две секции выполнения для maven-source-plugin

Вывод будет выглядеть примерно так:

    <plugin>
      <artifactId>maven-source-plugin</artifactId>
      <version>2.0.4</version>
      <executions>
        <execution>
          <id>attach-sources</id>
          <goals>
            <goal>jar</goal>
          </goals>
        </execution>
        <execution>
          <goals>
            <goal>jar</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

Чтобы решить эту проблему, найдите везде, где выиспользовали maven-source-plugin и убедитесь, что вы используете attach-sources "id", чтобы он совпадал с профилем выпуска.Затем эти разделы будут объединены.

В соответствии с передовой практикой для обеспечения согласованности необходимо настроить это в корневом POM вашего проекта в build> pluginManagement и NOT в дочерних poms.В дочернем pom вы просто указываете в build> plugins, что хотите использовать maven-source-plugin, но не предоставляете никаких исполнений.

В комнате pom.xml:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <executions>
          <execution>
            <!-- This id must match the -Prelease-profile id value or else sources will be "uploaded" twice, which causes Nexus to fail -->
            <id>attach-sources</id>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>    
  </pluginManagement>
</build>

Inребенок pom.xml:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-source-plugin</artifactId>
    </plugin>
  </plugins>
</build>
24 голосов
/ 08 июня 2016

Я знаю, что этот вопрос старый, но сегодня это был хит # 1 в Google, поэтому я добавлю свой ответ, подходящий для последних версий maven 3.

Симптом состоит в том, что источники и javadoc-файлы развертываются дважды, когдасборка релиза с некоторыми версиями maven 3. Если вы используете maven для развертывания своих артефактов в репозитории Sonatype Nexus, который позволяет загружать артефакт релиза только один раз (что вполне разумно), сборка завершается неудачно, когда втораяПопытка загрузки отклонена.Argh!

В версиях Maven с 3.2.3 по 3.3.9 есть ошибки - см. https://issues.apache.org/jira/browse/MNG-5868 и https://issues.apache.org/jira/browse/MNG-5939. Эти версии генерируют и разворачивают исходные файлы и javadoc-файлы дважды при выполнении выпуска.

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

Вместо сложной настройкимой pom, мой простой обходной путь должен был вернуться к Maven версии 3.2.1.

6 голосов
/ 07 ноября 2012

Просто столкнувшись с той же проблемой, я немного проанализировал ее. mvn release:perform оценивает файл release.properties, затем извлекает тег во временный каталог и вызывает что-то вроде

/usr/bin/mvn -D maven.repo.local=... -s /tmp/release-settings5747060794.xml
    -D performRelease=true -P set-envs,maven,set-envs deploy

Я попытался воспроизвести это - вручную проверил тег, созданный release:prepare, и вызвал это:

mvn -D performRelease=true -P set-envs,maven,set-envs deploy

Я получил тот же результат: он дважды пытался загрузить файл -sources.jar.

Как отметил qualidafial в комментарии, настройка performRelease=false вместо этого пропускает одно из двух вложений одного и того же файла.

У меня нет ни малейшего представления о том, как (или любой другой плагин) для развертывания *1016* использует это свойство.

Мы можем предоставить этот параметр как конфигурацию для maven-relayse-plugin:

<build>
    <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
                <useReleaseProfile>false</useReleaseProfile>
            </configuration>
        </plugin>
    </plugins>
</build>

Теперь я добавил строку <useReleaseProfile>false</useReleaseProfile> ко всем POM, и похоже, что освобождение теперь работает без сообщения об ошибке.

3 голосов
/ 22 января 2016

Я некоторое время боролся с этой проблемой и, наконец, смог решить ее в нашей инфраструктуре.Ответы здесь не помогли мне, так как у нас не было многократного выполнения целей исходного плагина, и конфигурация показалась нам подходящей.

Что мы упустили, так это связали выполнение исходного плагинав фазу.Расширение примера Bae, включая строку install для выполнения, решило проблему для нас:

<plugin> <artifactId>maven-source-plugin</artifactId> <version>2.0.4</version> <executions> <execution> <id>attach-sources</id> <phase>install</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>

Я подозреваюрешение лежит в этом ответе здесь ;похоже, что разные плагины вызывают выполнение jar target / attach-sources.Связывая наше выполнение с определенной фазой, мы заставляем наш плагин запускаться только на этой фазе.

0 голосов
/ 04 августа 2017

ПОЭТОМУ эта проблема некоторое время ломала нашу сборку, и ответ был ни один из вышеперечисленных. Вместо этого я по глупости установил для безвредного на вид приложения appendAssemblyId значение false в модуле-сборке-сборке для артефакта, который присоединяется (читай развернут, выпущен) с нашим основным артефактом. E.g.:

    <execution>
        <id>ci-groovy-distrib</id>
        <phase>package</phase>
        <goals>
            <goal>single</goal>
        </goals>
        <configuration>
            <descriptorRefs>
                <descriptorRef>my-extra-assembly</descriptorRef>
            </descriptorRefs>

            <!-- This is the BUG: the assemblyID MUST be appended 
                 because it is the classifier that distinguishes 
                 this attached artifact from the main one!
            -->
            <appendAssemblyId>false</appendAssemblyId>
            <!-- NOTE: Changes the name of the zip in the build target directory
                       but NOT the artifact that gets installed, deployed, releaseed -->
            <finalName>my-extra-assembly-${project.version}</finalName>
        </configuration>
    </execution>

В итоге:

  1. плагин сборки использует AssemblyId в качестве классификатора для артефакта, следовательно, существенную часть его уникальных координат GAV в терминах maven (на самом деле это больше похоже на координаты GAVC - C является классификатором) .

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

  3. Глупый элемент определяет только имя локального артефакта сборки и не играет никакой роли в остальной части. Это полная красная сельдь.

Краткое содержание резюме: Ошибка 400 от Nexus состояла в том, что наш дополнительный прикрепленный артефакт загружался поверх основного артефакта, поскольку он имел то же имя, что и основной артефакт, потому что у него были те же координаты GAVC, что и у основного артефакта, потому что я удалил единственная отличительная координата: классификатор, полученный автоматически из AssemblyId.

Расследование, чтобы выяснить, было ли это длинным и извилистым путем, ответ был тут же в документах для собрания мавенов:

appendAssemblyId

  • булево

  • Установите в false, чтобы исключить идентификатор сборки из конечного имени сборки и создания результирующей сборки Артефакты без классификатора. Таким образом, сборочный артефакт, имеющий тот же формат, что и упаковка текущего проекта Maven заменит файл для этого основного артефакта проекта .

  • Значение по умолчанию: true.
  • Свойство пользователя: assembly.appendAssemblyId.

С http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach

Дополнительный жирный шрифт принадлежит мне. Документы должны иметь большое вспыхивающее предупреждение: «Установите это в false и оставьте все надежды»

В этом ответе я получил некоторую помощь о другой проблеме maven-assembly-plugin: Как использовать appendAssemblyId Там очень помогло объяснение от Тунаки.

0 голосов
/ 13 мая 2016

Плагины Maven в родительских и дочерних помпах не должны иметь исполнения. Согласно стандартному соглашению, определите все плагины с исполнением / целями в родительском pom в разделе управления плагинами. Дочерний pom не должен переопределять вышеуказанные детали, а должен упоминать только тот плагин (с artifactId и version), который должен быть выполнен.

У меня была похожая проблема с maven-assembly-plugin с родительским pom, как показано ниже:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <descriptors>
                        <descriptor>src/assembly/assembly.xml</descriptor>
                    </descriptors>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

И у Child pom был maven-assembly-plugin, как показано ниже:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.2-beta-5</version>
            <configuration>
                <finalName>xyz</finalName>
                <descriptors>
                    <descriptor>src/assembly/assembly.xml</descriptor>
                </descriptors>
            </configuration>
            <executions>
                <execution>
                    <id>xyz-distribution</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Снятие <executions> с ребенка помогла исправить проблему. У эффективного pom было 2 выполненных выполнения, вызывая двойную установку к репозиторию Nexus.

0 голосов
/ 30 ноября 2015

У меня была такая же проблема. Как правило, сообщение об ошибке выдается, когда артефакты отправляются в Nexus дважды. Это может быть дважды для одного и того же хранилища Nexus или даже для разных хранилищ в пределах одного и того же Nexus.

Однако причины такой неверной конфигурации могут различаться. В моем случае, артефакты были загружены правильно во время шага сборки mvn clean deploy в Jenkins, но затем потерпели неудачу при попытке второго развертывания. Это второе развертывание было настроено на шаге пост-сборки Jenkins «Опубликовать артефакты в репозитории Maven».

0 голосов
/ 30 ноября 2010

Я настроил подключаемый модуль релиза maven с releaseProfile = false и не выполняю исходный профиль артефактов. Который сделал трюк.

<build>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.1</version>
                    <configuration>
                            <arguments>-P!source-artifacts</arguments>
                            <useReleaseProfile>false</useReleaseProfile>
                            <goals>-Dmaven.test.skip=true deploy</goals>
                    </configuration>    
                </plugin>
            </plugins>
        </build>
0 голосов
/ 23 ноября 2010

Я не думаю, что пробм находится в плагине релиза, я думаю, что вы подключили xxx-sources.jar два раза - вот почему дубликат загрузки. Почему существует дублированное вложение, трудно понять, не видя POM. Попробуйте запустить mvn -X и проверить журнал, кто подключает xxx-source.jar в другой раз.

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

...