Плагин выпуска Maven не работает: исходные артефакты развертываются дважды

Ответ 1

Попробуйте запустить 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, и убедитесь, что вы используете источники прикрепления "id", чтобы он был таким же, как и профиль выпуска. Затем эти разделы будут объединены.

Лучшая практика говорит о том, что для обеспечения согласованности вам нужно настроить это в корневой POM вашего проекта в build > pluginManagement и NOT в ваших детских помпах. В дочернем 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>

В дочернем pom.xml:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-source-plugin</artifactId>
    </plugin>
  </plugins>
</build>

Ответ 2

Я знаю, что этот вопрос старый, но сегодня он стал хитом №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 jar дважды при выполнении релиза.

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

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

Ответ 3

Просто поразив ту же проблему, я немного ее проанализировал. 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 вместо этого опускает одно из двух вложений одного и того же файла.

Я действительно не знаю, как это развернуть плагин (или любой другой плагин).

Мы можем предоставить этот параметр в качестве конфигурации для maven-relase-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, и похоже, что освобождение теперь работает без сообщения об ошибке.

Ответ 4

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

То, что мы пропустили, состояло в том, чтобы связать выполнение исходного плагина с фазой. Расширение примера на Bae, включая строку < фазa > установить </phase> , чтобы решить проблему:

<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/выполнение приложенных источников. Связывая наше исполнение с определенной фазой, мы заставляем наш плагин запускаться только на этой фазе.

Ответ 5

Это происходило со мной при запуске

mvn install deploy

Я избежал проблемы, вместо этого запустив

mvn deploy

(что подразумевает установку). В моем случае только один артефакт пытался загрузить дважды, и это был вторичный артефакт (maven-jar-plugin был настроен для создания вторичного jar в дополнение к тому, который был создан при выполнении default-jar).

Ответ 6

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

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

Ответ 7

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

Однако причины такой неправильной конфигурации могут быть разными. В моем случае, артефакты были загружены правильно во время mvn clean deploy build step в Jenkins, но затем не удалось, когда было предпринято второе развертывание. Это второе развертывание было настроено на этапе сборки Jenkins post "Публикация артефактов в репозитории Maven".

Ответ 8

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

У меня была аналогичная проблема с 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>

И у ребенка 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 устранило проблему. У эффективного pom было выполнено 2 выполнения, заставляя дублировать установку на Nexus repo.

Ответ 9

FWIW эта проблема немного нарушала нашу сборку, и ответ не был никем. Вместо этого я по-дурацски установил, казалось бы, безобидный appendAssemblyId в false в плагин maven-assembly-plugin для артефакта, который прикрепляется (читается развернутым, выпущенным) с нашим основным артефактом. Например:.

    <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>

Вкратце:

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

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

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

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

Исследование, чтобы найти это, было длинным и извилистым путем, который ответ был прямо там в документах для maven-assembly:

appendAssemblyId

• булево

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

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

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

Дополнительный смелый - мой. Документы должны иметь большое предупреждение: "Установите для этого значение false и отказаться от надежды"

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

Ответ 10

Я сконфигурировал подключаемый модуль maven release с 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>