Как лучше хранить информацию о версии Subversion в EAR?

Question

При получении сообщения об ошибке или сообщения "не работает" один из моих начальных вопросов всегда имеет какую версию? Поскольку различные сборки находятся на многих этапах тестирования, планирование и развертывание часто являются нетривиальным вопросом.

В случае выпуска файлов Java JAR (ear, jar, rar, war), я хотел бы иметь возможность просматривать / находить JAR и переключаться на ту же ветку, версию или тег, который был источником выпущенного JAR.

Как наилучшим образом настроить процесс сборки ant, чтобы информация о версии из проверки svn оставалась в созданной сборке?

Я думал так:

• добавление файла VERSION, но с каким содержимым?
• хранение информации в файле META-INF, но под каким свойством и каким содержимым?
• копирование источников в архив результатов
• добавил svn: свойства ко всем источникам с ключевыми словами в местах, где компилятор оставляет их равными

---

В итоге я использовал подход svnversion (принятый anwser), потому что он сканирует все поддерево, а не информацию svn, которая просто просматривает текущий файл / каталог. Для этого я определил задачу SVN в файле ant, чтобы сделать ее более переносимой.

<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask">
  <classpath>
    <pathelement location="${dir.lib}/ant/svnant.jar"/>
    <pathelement location="${dir.lib}/ant/svnClientAdapter.jar"/>
    <pathelement location="${dir.lib}/ant/svnkit.jar"/>
    <pathelement location="${dir.lib}/ant/svnjavahl.jar"/>
  </classpath>        
</taskdef>

Не все сборки приводят к веб-сервисам. Файл ear перед развертыванием должен оставаться с тем же именем из-за обновления на сервере приложений. Сделать исполняемый файл все еще можно, но до тех пор я просто включаю файл информации о версии.

<target name="version">
  <svn><wcVersion path="${dir.source}"/></svn>
  <echo file="${dir.build}/VERSION">${revision.range}</echo>
</target>

Refs:
svnrevision: http://svnbook.red -bean.com / ru / 1.1 / re57.html
svn info http://svnbook.red -bean.com / ru / 1.1 / re13.html
Подклипс SVN задача: http://subclipse.tigris.org/svnant/svn.html
SVN-клиент: http://svnkit.com/

Answer 1

Используйте команду svnversion в вашем скрипте Ant, чтобы получить номер редакции:

<exec executable="svnversion" outputproperty="svnversion" failonerror="true">
  <env key="path" value="/usr/bin"/>
  <arg value="--no-newline" />
</exec>

Затем используйте свойство $ {svnversion} где-нибудь в вашем EAR. Мы помещаем его в имя файла EAR, но вы также можете поместить его в файл readme или версию внутри EAR или указать версию в EAR META-INF / manifest.mf :

<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />

Answer 2

Вы хотите указать номер ветви и хранилища Subversion. Как описано в Как получить доступ к текущему номеру сборки Subversion? , команда svn info предоставит вам эту информацию, которую вы затем сможете использовать для создания файла VERSION или для размещения в любом из других файлов, которые вы встраиваем в ваши * AR файлы. Если у вас больше ничего нет, вы можете использовать задачу XmlProperty Ant для извлечения соответствующей информации из выходных данных вашего Команда svn info --xml

Answer 3

Ознакомьтесь с проектом jreleaseinfo . Содержит задачу ANT, которая может генерировать класс Java, который можно вызывать во время выполнения для отображения информации о выпуске для вашего проекта.

Мне нравится его простота.

Answer 4

См. Также этот вопрос: Нумерация сборки и версии для проектов Java (ant, cvs, hudson)

Включает несколько полезных фрагментов кода.

Answer 5

Почему бы не поместить номер сборки в файл свойств ... это может быть легко прочитано Java и выведено в Help | О диалоге (апплет / приложение), нижнем колонтитуле веб-страницы или любом другом графическом интерфейсе, который у вас может быть.

(см. Нижний колонтитул на каждой странице SOF .... там указан номер версии SVN.)

Кажется, что груз легче, чем смотреть в WAR / EAR / JAR и т. Д. Easy Time?

Answer 6

Выполнять автоматическую сборку и помещать тег (с отметкой даты) в кодовую базу, когда сборка завершается успешно (с курсом unittest)

В процессе доставки доставляйте заказчику только помеченные сборки. Таким образом, вы управляете и можете разместить имя тега в файле readme.txt где-нибудь, или имя файла в файле ear должно отражать имя тега.

Я лично перешел на CVS, и это одна из причин. В CVS у меня может быть отчет о классе, это тег. Все мои jar-файлы содержат «main», что делает их работоспособными. С вопросами поддержки я прошу клиента сделать «java -jar somejar.jar» и выслать мне вывод вместе с вопросом.

Таким образом, я уверен в сборке, которую они используют, и даже могу получить информацию, такую ​​как версия Java, тип ОС и версия. Без необходимости отвечать на странные вопросы.

Это просто, но очень эффективно.

Answer 7

В первой части нашей сборки мы создаем файл version.txt в корне пакета и выгружаем тег, используемый для проверки кода из (в нашем случае) CVS ... Кроме того, заключительная часть нашего Процесс сборки проверяет полностью построенный EAR обратно в CVS для дальнейшего использования.

Таким образом, если у нас есть проблема с веб-приложением - это всего лишь случай попросить репортера нажать /app/version.txt - оттуда мы можем перейти к конкретной истории сборки в CVS, чтобы найти соответствующие компоненты ( обрабатывает разные версии библиотек в приложениях), чтобы найти ошибку.

Не уверен, насколько это поможет нашим опорным людям - но они определенно что-то жалуются на не нахождение там!

Answer 8

Из глубины моего разума. Тег для каждой сборки jar?

Answer 9

Я храню абсолютную ревизию репозитория как часть моего полного номера версии. Это дает людям быстрый взгляд, чтобы увидеть, есть ли данное изменение в данной версии или нет.

Мы также храним номер версии / дату сборки / и т. Д. В файле манифеста уха как пользовательские свойства, в основном они носят информационный характер. Мы также храним его в файле свойств, который встроен в наш jar-файл, чтобы приложение могло его прочитать.