Уничтожение локального хранилища Maven на машине сборки

Ответ 1

Плагин зависимостей Maven имеет purge-local-repository цель, которая позволяет удалять зависимости для данного проекта из локального репозитория, если это выполняется один раз в день по каждому проекту, моментальные снимки не будут накапливаться.

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

Например (обратите внимание, что может потребоваться некоторая настройка, как я сделал это из памяти):

<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
    <execution>
      <phase>package</phase>
      <configuration>
        <tasks>
          <delete>
            <fileset dir="${settings.localRepository}">
              <include name="**/*.jar"/>
              <exclude name="**/*.pom"/>
              <exclude name="**/*.war"/>
              <exclude name="**/*.ear"/>
              <exclude name="**/*.md5"/>
              <exclude name="**/*.sha"/>
              <!--any other extensions?...-->
              <!--match the timestamp pattern-->
              <containsregexp expression="[0-9]{8}.[0-9]{6}-[0-9]+"/>
            </fileset>
          </delete>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Ответ 2

Если вы используете hudson, вы можете настроить запланированное задание, чтобы просто удалить весь репозиторий один раз в день или что-то в этом роде. У меня есть работа под названием hudson-maven-repo-clean, которая имеет такую ​​конфигурацию:

• Сборка/выполнение оболочки: rm -rf ~hudson/.m2/repository
• Периодически создавать триггеры/сборку: 0 0 * * *

Ответ 3

В дополнение к очистке-локальному репозиторию (который читается мне как ядерная опция, поскольку он предлагает только конфигурацию excludes в отличие от явного includes), посмотрите на Удалить Project Artifact mojo. Я хочу реализовать его сейчас, так как мой конкретный вариант использования - очистить крупные снимки WAR и EAR, которые создаются на моих машинах CI (и иногда на рабочих станциях).

Ответ 4

Мы специально используем для этого сборщик-помощник. В нашей компании родительский pom - цель remove-project-artifact, встроенная в профиль для наших hudson-сборок. Таким образом, все старые версии этого артефакта удаляются до установки текущей версии.

...
<profile>
  <id>hudson</id>
  <activation>
    <property>
      <name>BUILD_TAG</name>
    </property>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.7</version>
        <executions>
          <execution>
            <id>remove-old-artifacts</id>
            <phase>package</phase>
            <goals>
              <goal>remove-project-artifact</goal>
            </goals>
            <configuration>
              <removeAll>true</removeAll>
            </configuration>
          </execution>
        </executions>
      </plugin>
  ...

Использование removeAll, установленное в true, уничтожит все остальные снимки, кроме той, на которой вы работаете. Это может быть опасно, так как это может означать, что снимки для ветки также будут уничтожены.

Например, если у вас есть snapshot 1.0.0.18-SNAPSHOT, представляющий HEAD и snapshot 1.0.1.17-SNAPSHOT, представляющие ветку, запуск этого плагина с помощью сборки 1.0.0.18-SNAPSHOT приведет к уничтожению папки 1.0.1.17-SNAPSHOt.

Чтобы обойти этот сценарий, removeAll должен быть установлен в false.

Ответ 5

Мы использовали немного другую (и коварную) технику. Все артефакты, которые строят "большие вещи" (EAR, WARs, TAR), имеют место для их развертывания, например:

<properties>
   <discard-me-in-bit-bucket>file://${basedir}/target/_DELETEME</discard-me-in-bit-bucket> 
</properties>

<distributionManagement>
  <repository>
    <id>upload-InternalSite</id>
    <name>SoftwareLibrary External</name>
    <url>${discard-me-in-bit-bucket}</url>
    <layout>legacy</layout>
    <uniqueVersion>false</uniqueVersion>
  </repository>
  <snapshotRepository>
    <id>upload-InternalSite</id>
    <name>Repository Name</name>
    <url>${discard-me-in-bit-bucket}</url>
    <layout>legacy</layout>
    <uniqueVersion>false</uniqueVersion>
  </snapshotRepository>
</distributionManagement>

Эта стратегия заставляет цель развертывания помещать вещи в целевой каталог, который, конечно же, уничтожается следующей операцией CLEAN. Чтобы стать еще более агрессивным, у нас есть шаг postbuild, который делает это:

find -type d -name '*_DELETEME' -exec rm -rf '{}' ';' -prune || echo $?

Мы используем еще одну стратегию. В Hudson/Jenkins мы предоставляем файл настроек для размещения репозитория .m2 в рабочей области для задания. Это позволяет нам удалить весь репозиторий до или после задания. Это также делает видимыми артефакты в рабочей области, которые помогают отлаживать некоторые проблемы.

Ответ 6

Насколько велика файловая система? У нас есть 10gb, предназначенные для создания и zap-снимков старше 30 дней каждую ночь. Это похоже на работу

Выполняется ли сборка каждые X часов или при изменении кода? Переход на изменения кода уменьшит количество артефактов, не уменьшая охват.

Вы устанавливаете локальные снимки? Вам не нужно делать это во всех случаях. В большинстве случаев только локальные файлы, которые активно разрабатываются, должны устанавливаться локально.

Вы устанавливаете файлы EAR/WAR локально? Вы, вероятно, тоже им не нужны.

Сколько рабочих пространств вы держите? Мы используем hudson и сохраняем только последние 5 сборников.