Comments 24
Я тоже в свое время писал что-то подобное, но меня тогда интересовала только дата сборки jar-файла.
Сборка проекта была с помощью Ant-скрипта — может кому понадобится.
Кстати, параметр «Implementation-Version» — это одно из стандартных свойств манифеста и описано в виде константы вот тут: java.util.jar.Attributes.Name.IMPLEMENTATION_VERSION
Сборка проекта была с помощью Ant-скрипта — может кому понадобится.
Кстати, параметр «Implementation-Version» — это одно из стандартных свойств манифеста и описано в виде константы вот тут: java.util.jar.Attributes.Name.IMPLEMENTATION_VERSION
О, за константу — спасибо.
Гребаный хабр не дает вставлять код! Вот ссылка на сам ant-скрипт: pastebin.com/2iTzS0ir
А зачем прописывать версию в коде? Можно-же воспользоваться, например, Jenkins-ом, который отслеживает из какого сорца был построен какой jar.
Каждый раз, когда вижу maven'овские «скрипты» мне хочется выковырнуть себе глаза.
А вот мне хочется застрелится каждый раз когда понимаю что придется вручную скачивать либы, искать их зависимости, настраивать в ant/IDE структуру каталогов. А если еще разбиратся с чужим ant скриптом и пытаться понять всю цепочку тасков…
Но соглашусь что с непривыычки мавеновский конфиг кажется адским заклинанием. :)
Но соглашусь что с непривыычки мавеновский конфиг кажется адским заклинанием. :)
Для ant тоже есть система управления зависимостями — ivy.
А первый maven отбил мне охоту смотреть на второй.
А первый maven отбил мне охоту смотреть на второй.
Я тоже на ivy подсел. И доволен.
Гибкость анта с автоматикой зависимостей ivy мне больше нравится как подход посравнению с maven.
Гибкость анта с автоматикой зависимостей ivy мне больше нравится как подход посравнению с maven.
Для меня одно из важнейших преимуществ maven'а является структура проекта. Эту структу может импортировать любая современная IDE. И нет проблемы с переносом проекта между рабочими местами.
Ну это вроде как и преимущество. Но попробуйте выйти за рамки стандарта, тут все сложнее анта (ИМХО). Правдо последний раз с maven я связывался несколько лет назад, может сейчас и лучше стало в 3-ей версии.
Ant + Ivy имеют все что имеет мавен сохраняя гибкость. гибкость и полная ясность того что происходит на каждом шагу мне как-то больше нравится.
Проблем с переносом проектов пока не было особых. (Если об этом подумать в начале.)
А вот что мне в анте не нравится так это XML синтаксис.
Ant + Ivy имеют все что имеет мавен сохраняя гибкость. гибкость и полная ясность того что происходит на каждом шагу мне как-то больше нравится.
Проблем с переносом проектов пока не было особых. (Если об этом подумать в начале.)
А вот что мне в анте не нравится так это XML синтаксис.
Это потому что для представления зависимостей в человекочитаемом виде используется неприспособленный для этого XML. ;)
Если собираете мавеном, то в META-INF/maven через несколько уровней директорий есть файл properties с номером версии из pox.xml. Его обычно и использую.
Буквально вчера написал плагин для 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+
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+
Чем build.info лучше или хуже манифеста?
На мой взгляд, build.info удобнее для web-приложений. Maven упакует его внутрь war/ear файла и, перейдя по ссылке example.com/build.info, можно будет посмотреть текущую задеплоеную версию приложения. Нет необходимости писать дополнительные сервлеты, version.jsp и тп.
Для «одиноких» jar-файлов MANIFEST.MF, пожалуй, подходит больше.
Для «одиноких» jar-файлов MANIFEST.MF, пожалуй, подходит больше.
Мы сейчас то же самое пишем. Лучше это тем, что у нас приложения не пакуются ни в JAR, ни в WAR. Поэтому Manifest.mf, даже если и есть, не подхватыается. Приходится немного изобретать колесо.
Прикольно.
А есть идея как бы прочитать теперь инфу о всех .jar файлах в актуальном класспасе или даже виртуальной машине всей?
Это нпример для того чтобы в апликации показать из чего она собрана полностью автоматом. Например интересно если аппликация автоматически собирается…
А есть идея как бы прочитать теперь инфу о всех .jar файлах в актуальном класспасе или даже виртуальной машине всей?
Это нпример для того чтобы в апликации показать из чего она собрана полностью автоматом. Например интересно если аппликация автоматически собирается…
Можно сделать так:
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'ах нужно будет ище изворачиватьсяSign up to leave a comment.
Хранение и вывод версии в java-проекте