Retrascope

Хотелось бы при создании релиза ещё параллельно создавать svn tag. Политику именования тэгов можно оставить той же, что принята в buildbase.

ant-скрипты выбросить из проекта успеем. Я бы сохранил их хотя бы до нового релиза 0.1.2 (или, скорее, 0.2.1). Или в самом ближайшем будущем нас ждет полная замена buildbase на gradle?

Ещё замечены следующие отличия gradle-скрипта от ant-скрипта:

1) Команда ant clean, помимо удаления папок с бинарниками и дистрибутивом, ещё вычищает из рабочей директории проекта файлы и папки, гегнерируемые тестами (*.graphml, *.tst etc.)
Команда gradle clean этого не делает.

2) Команда gradle shortTest делает вроде бы то же самое, что и ant test.short, но при этом в лог gradle не печатаются сообщения, выводимые инструментом. Это неудобно.
Такая же проблема у команды gradle test, но для отладки проще разобраться с gradle shortTest, ибо она отрабатывает гораздо быстрее.

Sergey Smolov wrote:

Хотелось бы при создании релиза ещё параллельно создавать svn tag. Политику именования тэгов можно оставить той же, что принята в buildbase.

git-таги точно создаются, создание svn-тагов заявлено, я не проверял из-за отсутствия репозитория. Думаю, работать будет.

ant-скрипты выбросить из проекта успеем. Я бы сохранил их хотя бы до нового релиза 0.1.2 (или, скорее, 0.2.1). Или в самом ближайшем будущем нас ждет полная замена buildbase на gradle?

Главное - чтобы не было путаницы. Раньше номер версии хранился в version.properties покомпонентно, сейчас - в gradle.properties целиком. Если собирать попеременно ant и gradle - будет весело :)

1) Команда ant clean, помимо удаления папок с бинарниками и дистрибутивом, ещё вычищает из рабочей директории проекта файлы и папки, гегнерируемые тестами (*.graphml, *.tst etc.)
Команда gradle clean этого не делает.

Это можно добавить. А можно ли создавать все эти файлы не в рабочей директории, а чуть глубже, чтобы эти файлы svn-у на глаза вообще не попадались?

Alexey Demakov wrote:

Sergey Smolov wrote:

Хотелось бы при создании релиза ещё параллельно создавать svn tag. Политику именования тэгов можно оставить той же, что принята в buildbase.

git-таги точно создаются, создание svn-тагов заявлено, я не проверял из-за отсутствия репозитория. Думаю, работать будет.

Сейчас попробую сделать тестовый release.

Alexey Demakov wrote:

1) Команда ant clean, помимо удаления папок с бинарниками и дистрибутивом, ещё вычищает из рабочей директории проекта файлы и папки, гегнерируемые тестами (*.graphml, *.tst etc.)
Команда gradle clean этого не делает.

Это можно добавить. А можно ли создавать все эти файлы не в рабочей директории, а чуть глубже, чтобы эти файлы svn-у на глаза вообще не попадались?

Хорошо, мы заведем папку tmp в рабочей директории проекта - пусть gradle clean тогда её удаляет.

Sergey Smolov wrote:

Хорошо, мы заведем папку tmp в рабочей директории проекта - пусть gradle clean тогда её удаляет.

Правильнее куда-нибудь в build\test-results класть

Alexey Demakov wrote:

Sergey Smolov wrote:

Хорошо, мы заведем папку tmp в рабочей директории проекта - пусть gradle clean тогда её удаляет.

Правильнее куда-нибудь в build\test-results класть

Понял, так и сделаем

Добавил вывод тестов на консоль: r2000

Alexey Demakov wrote:

Добавил вывод тестов на консоль: r2000

А я тут для себя открыл опцию --debug у Gradle. Её не было бы достаточно для того, чтобы иметь лог тестов?

Sergey Smolov wrote:

А я тут для себя открыл опцию --debug у Gradle. Её не было бы достаточно для того, чтобы иметь лог тестов?

Там очень много мусора сыплется. --info более удобоваримо для отладки скрипта.

Sergey Smolov wrote:

Сделал пробный release. Обнаружены следующие неприятные отличия по части полученного результата:

1) tag действительно создался, но его политика именования отличается от принятой в проекте. Как бы Вы порекомендовали решать данную проблему?

Для единообразия можно переименовать ветки, соответствующие проекту Retrascope. Ветки, соответствующие его предыдущей инкарнации GAA Extractor (которая, к тому же, ни разу не релизилась), думаю, можно будет вообще грохнуть - особой ценности, кроме исторической, они не несут. Так что с этим пунктом ясно.

Sergey Smolov wrote:

1) tag действительно создался, но его политика именования отличается от принятой в проекте. Как бы Вы порекомендовали решать данную проблему?

gradle - convention based. Чем сильнее мы хотим быть особенными, тем больше придётся писать руками и тем сложнее это будет сопровождать. Поэтому в непринципиальных вопросах я бы следовал соглашениям. Если мы считаем, что текущая реализация плоха - можно предложить изменения в плагинах gradle. Можно, конечно, и просто дописать код в build.gradle

Например, формат версии в gradle не включает дату выпуска. Но мне эта возможность кажется удобной, поэтому я её перенес.

В данном случае я бы оставил всё как есть. Ну если очень хочется - можно переименовать старые ветки, хотя они же ничему не мешают?

Alexey Demakov wrote:

В данном случае я бы оставил всё как есть. Ну если очень хочется - переименовал старые ветки, хотя они же ничему не мешают?

Одинаковым образом поименованные ветки будут а) зрительно упорядочены хронологически правильным образом (сейчас, например, ветка с кодом следующего релиза будет в папке, лежащей выше папок с ветками 0.1.1 и 0.1.2 в структуре каталогов) и б) мое эстетическое чувство будет спокойно:-)

Впрочем, это ничему не мешает и всегда можно переименовать, если припрёт. Так что остаемся в рамках существующей ковенции.

А дата выпуска - это полезно, да.

Sergey Smolov wrote:

2) Изменилась структура каталогов в дистрибутиве. В частности, скрипты выполнения попали в папку bin. Сама структура каталогов дистрибутива нареканий не вызывает, но скрипты нужно будет поправить. Это я готов сделать сам.

Как я понимаю, скрипты запуска в дистрибутив кладет application plugin:
http://gradle.org/docs/current/userguide/application_plugin.html

Я навскидку не знаю, как их поменять, а в чём проблема?

Alexey Demakov wrote:

Sergey Smolov wrote:

2) Изменилась структура каталогов в дистрибутиве. В частности, скрипты выполнения попали в папку bin. Сама структура каталогов дистрибутива нареканий не вызывает, но скрипты нужно будет поправить. Это я готов сделать сам.

Как я понимаю, скрипты запуска в дистрибутив кладет application plugin:
http://gradle.org/docs/current/userguide/application_plugin.html

Я навскидку не знаю, как их поменять, а в чём проблема?

Проблемы нет, просто нужно не забыть сделать эту задачу, чтобы в итоге не получить неработающий билд.
В моих скриптах retrascope.sh и retrascope.bat используются некоторые предположения о структуре каталогов дистрибутива. Я их и поправлю.

Однако, я проглядел кое-что. Скрипты, которые Gradle кладет в папку bin дистрибутива - сгенерированные. А я думал, что он кладет туда наши скрипты и поэтому неверно истолковал Ваш вопрос.

В общем, для окончательного перехода на Gradle хотелось бы, чтобы в дистрибутив попадали следующие файлы: ChangeLog, LICENSE, NOTICE, README. Все остальное устраивает.

Sergey Smolov wrote:

3) javadoc-документация и исходные коды в дистрибутиве запакованы в jar-архивы. Это как-то странно. Тот же javadoc, думаю, можно было бы вообще не запаковывать, а исходники - положить в zip.

Jar заменен на Zip: r2008

Точно надо javadoc распаковывать? Мои соображения такие: это готовая программа, а не библиотека, дистрибутив нужен, чтобы с ней разобраться (документация) и запустить (скрипты и jar'ы). Javadoc и исходники - приятное дополнение для тех, кто полезет внутрь. Или у Retrascope есть API, которым необходимо пользоваться для использования инструмента?

4) Странно, что в дистрибутив не попали ChangeLog и LICENSE.

Добавил: r2008

В остальном все довольно неплохо -структура каталогов дистрибутива стала яснее, лишние jar-библиотеки были удалены и пр.

Кстати, о лишних библиотеках. В идеале share/jar в репозитории быть не должно. Зависимости лежат в maven/ivj репозитории удалённо, скачиваются по мере необходимости. Их версии указаны в build.gradle в блоке dependencies.
Известные мне публичные библиотеки, версии которых указаны в имени файла, я уже перенес. Остальные пока подключаются из dependencies{ files {...} }

Хорошо бы эту работу довести до конца.

Тут возникает одна проблема - при использовании eclipse зависимости должны лежать где-то в проекте.
Можно добавить специальную задачу, чтобы зависимости выкачивались в проект:

//copying all dependencies attached to 'compile' into a specific folder
task getDependencies(type: Copy) {
  //referring to the 'compile' configuration
  from configurations.compile, configurations.testCompile
  into 'libs'
}

Sergey Smolov wrote:

В общем, для окончательного перехода на Gradle хотелось бы, чтобы в дистрибутив попадали следующие файлы: ChangeLog, LICENSE, NOTICE, README. Все остальное устраивает.

NOTICE, README тоже добавлены: r2009

Alexey Demakov wrote:

Sergey Smolov wrote:

3) javadoc-документация и исходные коды в дистрибутиве запакованы в jar-архивы. Это как-то странно. Тот же javadoc, думаю, можно было бы вообще не запаковывать, а исходники - положить в zip.

Jar заменен на Zip: r2008

Точно надо javadoc распаковывать? Мои соображения такие: это готовая программа, а не библиотека, дистрибутив нужен, чтобы с ней разобраться (документация) и запустить (скрипты и jar'ы). Javadoc и исходники - приятное дополнение для тех, кто полезет внутрь. Или у Retrascope есть API, которым необходимо пользоваться для использования инструмента?

Ок, понял, давайте javadoc оставим в zip-архиве. Кстати, когда мы разработаем полноценную пользовательскую документацию для Retrascope - куда её порекомендуете класть, чтобы она попала в дистрибутив?

4) Странно, что в дистрибутив не попали ChangeLog и LICENSE.

Добавил: r2008

Отлично, спасибо!

В остальном все довольно неплохо -структура каталогов дистрибутива стала яснее, лишние jar-библиотеки были удалены и пр.

Кстати, о лишних библиотеках. В идеале share/jar в репозитории быть не должно. Зависимости лежат в maven/ivj репозитории удалённо, скачиваются по мере необходимости. Их версии указаны в build.gradle в блоке dependencies.
Известные мне публичные библиотеки, версии которых указаны в имени файла, я уже перенес. Остальные пока подключаются из dependencies{ files {...} }

Хорошо бы эту работу довести до конца.

Т.е. для того, чтобы проект успешно собирался, достаточно будет в репозитории оставить только эти библиотеки:

compile files( "${project.projectDir}/share/jar/fortress.jar" 
               , "${project.projectDir}/share/jar/jython.jar" 
               , "${project.projectDir}/share/jar/veritrans.jar" 
               , "${project.projectDir}/share/jar/zamiacad.jar" 
               )

?

Тут возникает одна проблема - при использовании eclipse зависимости должны лежать где-то в проекте.
Можно добавить специальную задачу, чтобы зависимости выкачивались в проект:

[...]

Это скорее не про Retrascope, а про Retrascope IDE. В данный момент это простенький плагин для Eclipse, который мы собираем ant-скриптом. Но за справку спасибо, буду знать, куда глядеть, чтобы и его перевести на Gradle.

Кстати, Requiality уже собирается с помощью Gradle?

Sergey Smolov wrote:

Кстати, когда мы разработаем полноценную пользовательскую документацию для Retrascope - куда её порекомендуете класть, чтобы она попала в дистрибутив?

Насколько я понимаю, соглашений по этому поводу нет. Просто добавим в build.gradle что-то типа

applicationDistribution.from( 'src/main/templates' ) {       
  into("templates")
}

Sergey Smolov wrote:

Т.е. для того, чтобы проект успешно собирался, достаточно будет в репозитории оставить только эти библиотеки:

[...]

?

Да.

Тут возникает одна проблема - при использовании eclipse зависимости должны лежать где-то в проекте.
Можно добавить специальную задачу, чтобы зависимости выкачивались в проект:

[...]

Это скорее не про Retrascope, а про Retrascope IDE. В данный момент это простенький плагин для Eclipse, который мы собираем ant-скриптом. Но за справку спасибо, буду знать, куда глядеть, чтобы и его перевести на Gradle.

Это относится ко всем проектам, разработка которых ведётся в Eclipse. Библиотеки из share/jar упоминаются в .classpath. Поэтому gradle сборка работать будет, а вот Eclipse будет ругаться до тех пор, пока библиотеки не будут скопированы в проект.

Кстати, Requiality уже собирается с помощью Gradle?

Пока нет :)

Alexey Demakov wrote:

Sergey Smolov wrote:

Тут возникает одна проблема - при использовании eclipse зависимости должны лежать где-то в проекте.
Можно добавить специальную задачу, чтобы зависимости выкачивались в проект:

[...]

Это скорее не про Retrascope, а про Retrascope IDE. В данный момент это простенький плагин для Eclipse, который мы собираем ant-скриптом. Но за справку спасибо, буду знать, куда глядеть, чтобы и его перевести на Gradle.

Это относится ко всем проектам, разработка которых ведётся в Eclipse. Библиотеки из share/jar упоминаются в .classpath. Поэтому gradle сборка работать будет, а вот Eclipse будет ругаться до тех пор, пока библиотеки не будут скопированы в проект.

Вроде существует Eclipse plugin, который решает задачу интеграции с Gradle: http://marketplace.eclipse.org/content/gradle-integration-eclipse-44

Sergey Smolov wrote:

Вроде существует Eclipse plugin, который решает задачу интеграции с Gradle: http://marketplace.eclipse.org/content/gradle-integration-eclipse-44

Насколько я понял, это не интеграция проектов, собираемых gradle, с Eclipse. Это поддержка разработки gradle скриптов в Eclipse. Я пытался с ним подружиться, но так и не понял, как им пользоваться.

Если все хотелки по этому тикету выполнены, его, наверное, можно закрывать?