Как вы эффективно справляетесь с моментальными снимками maven-3?

Теперь, когда maven-3 отказался от поддержки false для артефактов моментальных снимков, кажется, что вам действительно нужно использовать timestamped SNAPSHOTS. Особенно сильно влияет на m2eclipse, который использует maven 3 внутри себя, обновления-снимки не работают, когда SNAPSHOTS не уникальны.

Казалось, что лучше всего установить все снимки в uniqueVersion = false

Теперь, кажется, нет большой проблемы переключиться на timestamped версию, после того, как все они управляются центральным репозиторием nexus, который может удалять старые снимки в обычных интервалах.

Проблема заключается в локальных рабочих станциях разработчиков. Их местный repository быстро растет очень просто, с уникальными моментальными снимками.

Как справиться с этой проблемой?

Сейчас я вижу следующие возможные решения:

  • Попросите разработчиков регулярно очищать repository (что приводит к большому количеству фрустрации, так как требуется много времени для удаления и даже дольше, чтобы загрузить все необходимое)
  • Настройте некоторый скрипт, который удалит все каталоги SNAPSHOT из локального репозитория и попросит разработчиков время от времени запускать этот сценарий (лучше, чем первый, но все еще занимает довольно много времени для запуска и загрузки текущих снимков)
  • используйте зависимость: плагин purge-local-repository (возникают проблемы при запуске из eclipse из-за открытых файлов, которые должны запускаться из каждого проекта)
  • настроить связь на каждой рабочей станции и настроить работу по очистке старых снимков (лучший результат, но я не хочу поддерживать 50 + серверы nexus, а память всегда плотно работает на рабочих станциях разработчиков)
  • прекратить использование SNAPSHOTS вообще

Каков наилучший способ сохранить ваш локальный repository в заполнении вашего пространства на жестком диске?

Обновить:

Чтобы проверить beaviour и дать больше информации, я настраиваю небольшой сервер nexus, создайте два проекта (a и b) и попробуйте:

а:

 4.0.0 de.glauche a 0.0.1-SNAPSHOT   nexus nexus http://server:8081/nexus/content/repositories/snapshots    

б:

  4.0.0 de.glauche b 0.0.1-SNAPSHOT   nexus nexus http://server:8081/nexus/content/repositories/snapshots/     nexus nexus  true  http://server:8081/nexus/content/repositories/snapshots/     de.glauche a 0.0.1-SNAPSHOT    

Теперь, когда я использую maven и запускаю «развернуть» на «a», у меня будет

 a-0.0.1-SNAPSHOT.jar a-0.0.1-20101204.150527-6.jar a-0.0.1-SNAPSHOT.pom a-0.0.1-20101204.150527-6.pom 

в локальном хранилище. С новой версией timestamp каждый раз, когда я запускаю цель развертывания. То же самое происходит, когда я пытаюсь обновить снимки с сервера nexus (закрыть «a» Project, удалить его из локального репозитория, построить «b»)

В среде, где много снимков получают сборку (думаю, hudson server …), локальная репозитория быстро заполняется старыми версиями

Обновление 2:

Чтобы проверить, как и почему это происходит, я сделал еще несколько тестов. Каждый тест выполняется против чистого (de / glauche получает удаление с обеих машин и связи)

  • mvn развертывание с maven 2.2.1:

локальный repository на машине A содержит snapshot.jar + snapshot-timestamp.jar

НО: только одна метка времени в связи, метаданные читают:

   de.glauche a 0.0.1-SNAPSHOT   20101206.200039 1  20101206200039   
  • (на машине B) в m2eclipse (встроенный m3 final) -> локальный repository имеет snapshot.jar + snapshot-timestamp.jar 🙁
  • запустить цель пакета с внешним maven 2.2.1 -> в локальном репозитории есть snapshot.jar + snapshot-timestamp.jar 🙁

Итак, попробуйте с maven 3.0.1 (после удаления всех следов проекта a)

  • локальный repository на машине A выглядит лучше, только один флажок без отметки времени

  • только одна метка времени в связи, метаданные читают:

    de.glauche a 0.0.1-SNAPSHOT

      20101206.201808 3  20101206201808   jar 0.0.1-20101206.201808-3 20101206201808   pom 0.0.1-20101206.201808-3 20101206201808   
  • (на машине B) в m2eclipse (встроенный m3 final) -> локальный repository имеет snapshot.jar + snapshot-timestamp.jar 🙁

  • запустить цель пакета с внешним maven 2.2.1 -> в локальном репозитории есть snapshot.jar + snapshot-timestamp.jar 🙁

Итак, напомним: цель «развертывания» в maven3 работает лучше, чем в 2.2.1, локальный repository на создающей машине выглядит отлично. Но приемник всегда заканчивается множеством временных версий …

Что я делаю не так ?

Обновление 3

Я также тестировал различные другие конфигурации, сначала заменил nexus artifactory -> такое же поведение. Затем используйте linux maven 3 клиента для загрузки снимков из диспетчера хранилища -> локальный repository по-прежнему имеет временные снимки 🙁

6 Solutions collect form web for “Как вы эффективно справляетесь с моментальными снимками maven-3?”

применяется к артефактам, которые были развернуты (через mvn deploy) в repository Maven, например Nexus.

Чтобы удалить их из Nexus, вы можете легко создать автоматическое задание для ежедневной очистки репозитория SNAPSHOT. Он может быть настроен на сохранение определенного количества снимков или сохранение их в течение определенного периода времени. Его супер легко и отлично работает.

Артефакты в локальном репозитории на машине разработчика попадают туда из цели «установить» и не используют эти временные метки … они просто продолжают заменять одну и только версию SNAPSHOT, если вы не увеличиваете номер версии (например, 1.0.0- SNAPSHOT – 1.0.1-SNAPSHOT).

Этот плагин удаляет артефакты проекта из локального репозитория. Полезно хранить только одну копию большого локального снимка.

  org.codehaus.mojo build-helper-maven-plugin 1.7   remove-old-artifacts package  remove-project-artifact   true     

Ну, мне не понравилось ни одно из предлагаемых решений. Удаление кеша maven часто значительно увеличивает сетевой трафик и замедляет процесс сборки. build-helper-maven-plugin помогает только с одним артефактом, мне нужно решение, которое может очистить все устаревшие временные артефакты моментального снимка из локального кеша одной простой командой. После нескольких дней поиска я сдался и решил написать небольшую программу. Заключительная программа, похоже, работает очень хорошо в нашей среде. Поэтому я решил поделиться им с другими, кому может понадобиться такой инструмент. Источники можно вытащить из github: https://github.com/nadestin/tools/tree/master/MavenCacheCleanup

Что касается удаленной части репозитория, я думаю, что предыдущие ответы, которые обсуждают очистку SNAPSHOTs на регулярном интервале, будут работать. Но никто не обратился к части синхронизации вашей рабочей станции локального разработчика.

Мы еще не начали использовать Maven3, поэтому нам еще предстоит увидеть, как SNAPSHOTs начинают наращивать работу на локальных машинах.

Но у нас были разные проблемы с m2eclipse. Когда у нас есть разрешение «Разрешение рабочей области» и проект существует в нашей рабочей области, обновления источника обычно удерживают нас на краю кровотечения. Но мы обнаружили, что очень сложно получить m2eclipse, чтобы обновить себя недавно опубликованными артефактами в Nexus. Мы сталкиваемся с аналогичными проблемами в нашей команде, и это особенно проблематично, потому что у нас очень большой график проектов … есть много зависимостей, которые не будут в вашей рабочей области, но будут часто публиковать публикации SNAPSHOT.

Я почти уверен, что это сводится к проблеме в m2eclipse, где он не обрабатывает SNAPSHOTs точно так, как должен. Вы можете увидеть на консоли Maven в eclipse, где m2eclipse сообщает вам, что она пропускает обновление недавно опубликованной SNAPSHOT, потому что у нее есть кешированная версия. Если вы выполните команду -U из конфигурации запуска или из командной строки, Maven заберет метаданные. Но выбор «Обновить моментальные снимки …» должен указывать m2eclipse, чтобы Maven завершил этот кеш. Кажется, он не проходит мимо. Кажется, есть ошибка, которая подана для этого, если вы заинтересованы в голосовании за нее: https://issues.sonatype.org/browse/MNGECLIPSE-2608

Вы упомянули об этом в комментарии где-то.

Лучшим обходным решением этой проблемы, по-видимому, является то, что разработчики чистят свои локальные рабочие станции, когда что-то начинает разрушаться из-за m2eclipse. Аналогичное решение для другой проблемы … Другие сообщили о проблемах с Maven 2.2.1 и 3, поддерживая m2eclipse, и я видел то же самое.

Я хотел бы надеяться, что если вы используете Maven3, вы можете настроить его, чтобы вытащить только последний SNAPSHOT и кеш, который за время, о котором говорит repository (или пока вы не закончите его вручную). Надеюсь, вам не понадобится иметь кучу SNAPSHOTs, сидящих в вашем местном репозитории.

То есть, если вы не говорите о сервере сборки, который вручную делает mvn install на них. Что касается того, как предотвратить создание SNAPSHOTs в среде, такой как сервер сборки, мы как бы уклонились от этой пули, поскольку каждая assembly использует свое собственное рабочее пространство и локальный repository (хотя в Maven 2.2.1 некоторые вещи, такие как Кажется, что POM всегда выходят из ~ / .m2 / repository). Дополнительные SNAPSHOT действительно поддерживают только одну строчку, а затем они удаляются (и загружаются снова с нуля). Таким образом, мы видели, что этот подход в конечном итоге съедает больше места для начала, но он имеет тенденцию оставаться более стабильным, чем все, что разрешено из одного репозитория. Этот параметр (на Hudson) называется «Использовать частный repository Maven» и находится под кнопкой «Дополнительно» раздела «Сборка» в конфигурациях проекта, когда вы выбрали для сборки с Maven. Вот описание справки для этой опции:

Как правило, Хадсон использует локальный repository Maven, определенный Maven – точный процесс кажется недокументированным, но он ~ / .m2 / repository и может быть переопределен в ~ / .m2 / settings.xml (подробнее см. Ссылку .) Это обычно означает, что все задания, выполняемые на одном узле, имеют один repository Maven. Поверхность этого заключается в том, что вы можете сохранить дисковое пространство, но недостатком этого является то, что иногда эти сборки могут мешать друг другу. Например, вы можете получить неправильные сборки, просто потому, что у вас есть все зависимости в вашем локальном репозитории, несмотря на то, что ни один из репозиториев в POM не может иметь их.

Также есть некоторые проблемы, связанные с одновременными процессами Maven, пытающимися использовать один и тот же локальный repository.

Когда эта опция будет отмечена, Хадсон скажет Maven использовать $ WORKSPACE / .repository в качестве локального репозитория Maven. Это означает, что каждое задание будет иметь собственный изолированный repository Maven только для себя. Он устраняет вышеуказанные проблемы за счет дополнительного дискового пространства.

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

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

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

В groovy удаление временных файлов, таких как artifact-0.0.1-20101204.150527-6.jar может быть очень простым:

 root = 'path to your repository' new File(root).eachFileRecurse { if (it.name.matches(/.*\-\d{8}\.\d{6}\-\d+\.[\w\.]+$/)) { println 'Deleting ' + it.name it.delete() } } 

Установите Groovy , сохраните скрипт в файл и заплатите за выполнение каждую неделю, запустите, войдите в систему, что вам подходит.

Или вы можете даже выполнить исполнение в maven build, используя gmavenplus-plugin . Обратите внимание, как определяется местоположение хранилища, установленное maven в settings.localRepository свойств.localRepository, а затем привязано через конфигурацию в repository переменных:

   org.codehaus.gmavenplus gmavenplus-plugin 1.3   install  execute       repository ${settings.localRepository}         org.codehaus.groovy groovy-all 2.3.7 runtime    во   org.codehaus.gmavenplus gmavenplus-plugin 1.3   install  execute       repository ${settings.localRepository}         org.codehaus.groovy groovy-all 2.3.7 runtime    

Добавьте следующий параметр в свой файл POM

POM

  true  

https://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html

Пример POM

   org.apache.maven.plugins maven-dependency-plugin 2.10   copy package  copy     junit junit 3.8.1 jar false ${project.build.directory}/alternateLocation optional-new-name.jar   **true** ${project.build.directory}/wars false true       

Настроить в Дженкинсе:

 // copy artifact copyMavenArtifact(artifact: "commons-collections:commons-collections:3.2.2:jar", outputAbsoluteArtifactFilename: "${pwd()}/target/my-folder/commons-collections.jar") 
Interesting Posts

Является ли «argv = имя исполняемого» принятым стандартом или просто общим соглашением?

Java – class.getResource возвращает null

Воспроизведение двух звуков одновременно

Получить TFS, чтобы игнорировать папку моих пакетов

объект объекта не может ссылаться на несколько экземпляров IEntityChangeTracker. при добавлении связанных объектов к объекту в Entity Framework 4.1

Java ResultSet, как проверить, есть ли какие-либо результаты

Пример общих предпочтений Android

Как я могу заставить emacs использовать другие css для публикации orgmode?

В браузере, как узнать, какой десятичный разделитель использует операционная система?

ASP.NET MVC: создан ли controller для каждого запроса?

Синглтон с аргументами в Java

ExpressJS Как структурировать приложение?

Как изменить разделитель по умолчанию в текстовом импортировании в Excel?

Как сделать глубокую копию объекта в Java?

Как обмениваться компьютером через беспроводной маршрутизатор в Windows?

Давайте будем гением компьютера.