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

Question

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

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

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

Я думал вдоль линий:

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

---

Я закончил с использованием svnversion подход (принятый anwser), потому что он просматривает все поддерево, а не svn info, которое просто смотрит на текущий файл/каталог. Для этого я определил задачу 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> 

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

<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/en/1.1/re57.html
СВН Информация http://svnbook.red-bean.com/en/1.1/re13.html
Subclipse задачи Svn: http://subclipse.tigris.org/svnant/svn.html
СВН клиента: http://svnkit.com/

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Кажется нагрузки легче, чем смотреть в WAR/EAR/JAR и т.д. непростое время?

Answer 7

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

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

Answer 8

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

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

Answer 9

Смотрите также вопрос: Build and Version Numbering for Java Projects (ant, cvs, hudson)

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