2

При использовании buildnumber для вычисления номеров новой версии внутри скрипта сборки муравьев плющ будет висеть до 20 минут при вычислении следующей версии. По мере увеличения количества сборок, он, по-видимому, растет экспоненциально (проект, который я тестировал, имеет около 600). Сначала я думал, что это может быть из-за больших файлов и проверки хэша, но потом я включил отладку и видел это около 1200 раз:Apache Ivy buildnumber болезненно медленный

[ivy:buildnumber] using ssh to list all in /Storage/ivy/status/base//module/version [ivy:buildnumber] SShRepository:list called: /Storage/ivy/status/base//module/version [ivy:buildnumber] found 12 urls [ivy:buildnumber] 0 matched /Storage/ivy/status/base//module/version/[artifact]-version.jar

По какой-то причине он рекурсии через каждый каталог, чтобы найти некоторые jar, и когда он не может найти то, что он ищет, он переходит к второму распознавателю и снова пытается. Конечно, он никогда не находит соответствия, потому что в любом каталоге нет банок.

Файл ivysettings выглядит следующим образом:

<ivysettings> 
     <property name="ivy.checksums" value="" /> 
     <property name="tisivy.host" value="builds.example.com" /> 
     <property name="tisivy.url.path" value="http://${tisivy.host}" /> 

     <property name="tisivy.file.path" value="/Storage/ivy" /> 
     <property name="tisivy.repo.pattern" value="[module]/[revision]" /> 
     <property name="tisivy.artifact.pattern" value="${tisivy.repo.pattern}/[artifact]-[revision].[ext]" /> 

     <settings defaultResolver="url-chain" /> 

     <caches/> 

     <resolvers> 
       <chain name="url-chain" returnFirst="true"> 
         <url name="http"> 
           <ivy pattern="${tisivy.url.path}/status/${tisivy.repo.pattern}/ivy.xml" /> 
           <artifact pattern="${tisivy.url.path}/status/${tisivy.artifact.pattern}" /> 
         </url> 
       </chain> 

       <ssh name="ssh" user="example" userPassword="****************" host="${tisivy.host}" publishPermissions="0644"> 
         <ivy pattern="${tisivy.file.path}/status/${tisivy.repo.pattern}/ivy.xml" /> 
         <artifact pattern="${tisivy.file.path}/status/${tisivy.artifact.pattern}" /> 
       </ssh> 
     </resolvers> 

     <triggers> 
     </triggers> 

     <statuses> 
       <status name="production" integration="false" /> 
       <status name="integration" integration="true" /> 
       <status name="status" integration="false" /> 
     </statuses> 

     <modules> 
     </modules> 

</ivysettings> 

Вызов номер сборки выглядит следующим образом: <ivy:buildnumber organisation="org" module="${ivy.module.doubleslash}" revision="${version.base}" />

Я не могу найти кого-либо еще сталкиваются с этой проблемой, поэтому я Я где-то ошибаюсь.

ответ

1

Я обычно говорить buildnumber задачу, которую RESOLVER использовать:

<ivy:buildnumber resolver="url-chain" 
       organisation="${ivy.organisation}" 
       module="${ivy.module}" 
       revision="${version.base}"/> 

В документации описывается поведение по умолчанию для поиска всех доступных арбитров. (Что имеет смысл, репозиция, которую вы публикуете, может быть не указана в настройке распознавателя по умолчанию).

Примечание:

  • Я использую ivy.organisation и ivy.module переменные, так как они устанавливаются автоматически из «информации» метка моего файла плюща.
+0

Я понимаю, почему он использует оба резователя. У меня он настроен на использование http, а затем ssh в качестве возврата (оба они смотрят на один и тот же репозиторий). Вопрос в самом деле, почему он делает поиск .jar, что я никогда не говорил ему искать. Если я просто скажу, что использовать только http, это сокращает время пополам, но для него все еще смешно, чтобы занять 10 минут, чтобы найти самое большое число. – kjones603

+0

@ user2576621 Решение ssh не входит в цепочку. Причина, по которой он проверяет оба, заключается в том, что это поведение по умолчанию (как объяснено). Что касается поиска банки, вы никогда не говорили об этом в поисках ... Я не понимаю (вы используете свойство «ivy.module.doubleslash», значение которого в вопросе не указано). Наконец, поиск по протоколу HTTP всегда будет быстрее, стоимость установки для SSH-соединения очень дорога для каждого поиска модулей. Очевидно, что какой-то пул соединений сделает это более эффективным, но я бы не понял, почему вы ищете оба РЕПО ... –

Смежные вопросы