Хранение и вывод версии в java-проекте

[@RealManPMI]

Я тоже в свое время писал что-то подобное, но меня тогда интересовала только дата сборки jar-файла.

Сборка проекта была с помощью Ant-скрипта — может кому понадобится.

Кстати, параметр «Implementation-Version» — это одно из стандартных свойств манифеста и описано в виде константы вот тут: java.util.jar.Attributes.Name.IMPLEMENTATION_VERSION

[@sandello]

О, за константу — спасибо.

[@RealManPMI]

Гребаный хабр не дает вставлять код! Вот ссылка на сам ant-скрипт: pastebin.com/2iTzS0ir

[@jbaruch]

А зачем прописывать версию в коде? Можно-же воспользоваться, например, Jenkins-ом, который отслеживает из какого сорца был построен какой jar.

[@sandello]

Отдал заказчику. А он говорит «не работает». Нужно узнать, что и почему. Выяснение версии «неработающего» кода — очень важный шаг. Вполне может оказаться, что заказчик не поставил последнюю присланную версию.

[@ostapbender]

Каждый раз, когда вижу maven'овские «скрипты» мне хочется выковырнуть себе глаза.

[@MercurieVV]

А вот мне хочется застрелится каждый раз когда понимаю что придется вручную скачивать либы, искать их зависимости, настраивать в ant/IDE структуру каталогов. А если еще разбиратся с чужим ant скриптом и пытаться понять всю цепочку тасков…
Но соглашусь что с непривыычки мавеновский конфиг кажется адским заклинанием. :)

[@allex]

Для ant тоже есть система управления зависимостями — ivy.

А первый maven отбил мне охоту смотреть на второй.

[@shuron]

Я тоже на ivy подсел. И доволен.
Гибкость анта с автоматикой зависимостей ivy мне больше нравится как подход посравнению с maven.

[@sandello]

Для меня одно из важнейших преимуществ maven'а является структура проекта. Эту структу может импортировать любая современная IDE. И нет проблемы с переносом проекта между рабочими местами.

[@shuron]

Ну это вроде как и преимущество. Но попробуйте выйти за рамки стандарта, тут все сложнее анта (ИМХО). Правдо последний раз с maven я связывался несколько лет назад, может сейчас и лучше стало в 3-ей версии.
Ant + Ivy имеют все что имеет мавен сохраняя гибкость. гибкость и полная ясность того что происходит на каждом шагу мне как-то больше нравится.
Проблем с переносом проектов пока не было особых. (Если об этом подумать в начале.)

А вот что мне в анте не нравится так это XML синтаксис.

[@iZENfire]

Это потому что для представления зависимостей в человекочитаемом виде используется неприспособленный для этого XML. ;)

[@ostapbender]

Аминь.

[@qwazer]

Ссылки на обсуждения темы на stackoverflow:
stackoverflow.com/questions/171828/how-best-to-store-subversion-version-information-in-ears
stackoverflow.com/questions/690419/build-and-version-numbering-for-java-projects-ant-cvs-hudson

[@sandello]

Ну да, там описано решение сходной задачи. Другой способ решения, другие инструменты: svn/cvs и ant. Наверняка и задача выросла из других предпосылок.

[@aib]

Если собираете мавеном, то в META-INF/maven через несколько уровней директорий есть файл properties с номером версии из pox.xml. Его обычно и использую.

[@DimaRad]

Буквально вчера написал плагин для maven, который генерит файл build.info, примерно следующего содержания:

project.name = project
project.version = 1.1-SNAPSHOT
build.time = 18 May 2011, 17:28:43 +04:00
#Могут быть любые System Properties, указанные в configuration
java.vm.vendor = Sun Microsystems Inc.
java.vm.name = Java HotSpot(TM) Server VM
java.runtime.version = 1.6.0_23-b05
#Mercurial
local.revision.number = ee9b78bcd6d9+
global.revision.id = 243+

[@sandello]

Чем build.info лучше или хуже манифеста?

[@DimaRad]

На мой взгляд, build.info удобнее для web-приложений. Maven упакует его внутрь war/ear файла и, перейдя по ссылке example.com/build.info, можно будет посмотреть текущую задеплоеную версию приложения. Нет необходимости писать дополнительные сервлеты, version.jsp и тп.
Для «одиноких» jar-файлов MANIFEST.MF, пожалуй, подходит больше.

[@voronaam]

Мы сейчас то же самое пишем. Лучше это тем, что у нас приложения не пакуются ни в JAR, ни в WAR. Поэтому Manifest.mf, даже если и есть, не подхватыается. Приходится немного изобретать колесо.

[@shuron]

Прикольно.
А есть идея как бы прочитать теперь инфу о всех .jar файлах в актуальном класспасе или даже виртуальной машине всей?
Это нпример для того чтобы в апликации показать из чего она собрана полностью автоматом. Например интересно если аппликация автоматически собирается…

[@sandello]

Можно сделать так:
try {
Enumeration resources = getClass().getClassLoader().getResources("META-INF/MANIFEST.MF");
while (resources.hasMoreElements()) {
URL url = resources.nextElement();
InputStream stream = url.openStream();
Manifest mf = new Manifest(stream);
Attributes atts = mf.getMainAttributes();
System.out.println("version: " + atts.getValue(Attributes.Name.IMPLEMENTATION_VERSION));
}
} catch (IOException e) {
e.printStackTrace();
}

При нескольких classloader'ах нужно будет ище изворачиваться

[@shuron]

Да, хорошая идея с .getResources(). Спасибо (Мало кармы, не могу ещё "+" ставить)
А с несколькими лоадермаи надо будет по иерархии навигировать.
в OSGI свои методы есть, надо будет почитать.