Category Archives: Version control
В рамках продолжения работ по плагину FreeMarker для MyBatis нужно было сделать сайт проекта, по аналогии с тем, как это сделано у mybatis-velocity. С сайтами такого рода я сталкивался неоднократно, но до этого не задумывался о том, как такие сайты делаются. Поэтому пришлось «реверсить» метод создания сайта. Посмотрев на верстку и погуглив, я обнаружил, что это – результат выполнения команды mvn site
. Однако на исходниках mybatis-velocity эта команда почему-то выдавала другой результат: сайт был похож, но стили были старые, отсутствовал логотип, и не было целой группы разделов «Project Reports». Допустив, что часть конфигурации находится в родительском pom.xml и берётся откуда-то из другого места, я стал шаманить с конфигами, пытаясь добиться, чтобы mvn site
выдавал точно такой сайт, который был выложен на github-pages. Через некоторое время мне это удалось, и я сделал всё по аналогии для своего проекта. И заодно решил написать гайд по тому, как это сделать.
Итак, в мавне есть встроенный механизм для генерации шаблонных сайтов проектов. В сгенерированном сайте автоматом будет инфа о полученном артефакте, о том, какие зависимости у него есть, как прописать артефакт к себе в pom.xml, список участников проекта, и ещё много разных отчётов. По умолчанию список генерируемых отчётов весьма велик, его можно уменьшить, а можно добавить ещё 🙂 Для того, чтобы вся балалайка завертелась, нужно запилить site.xml
. В нём прописываются настройки меню, внешнего вида сайта. Можно выбрать плагин для стилей – по умолчанию будет старенький стиль, fluido на бутстрапе выглядит поприкольнее. В папке xdocs
уже пишется сам контент. Формат простой и интуитивно понятный – я за полчаса по аналогии забацал свою страничку «Getting started». Одно тонкое место – чтобы избежать лишних пробелов до и после кодовой разметки, нужно чтобы не было пробелов между тегами <source/> и собственно исходным кодом. Ну и очень желательно уметь использовать <![CDATA[]]>
.
Далее, дополнительные плагины. Очень рекомендую встроить javadocs. Это, думаю, самое полезное. Для того, чтобы отчёт сгенерился вместе с остальными, достаточно добавить его в <repoting/>
. У меня был какой-то баг при генерации джавадоков, почему-то не компилировались классы из test
. Пришлось заигнорить goal javadoc-test
.
После того, как мавно сделает вам сайт, вы можете его просто залить на GitHub Pages – либо в отдельный репозиторий, либо в этот же проект веткой gh-pages
.
В остальном проще не расписывать подробно, что к чему, а просто дать ссылку на пример того, как это настроено в моём случае: https://github.com/elw00d/mybatis-freemarker. Можно просто копировать конфиги и изменять по своему усмотрению.
Сегодня Тимур мне рассказал, что для градла есть удобнейшая штука – враппер. Например, вы используете gradle с версией X (икс). И ваш скрипт сборки точно будет работать на этой версии. Будет ли он работать на других версиях – вопрос. Программист, скачавший ваш репозиторий с кодом и скриптами сборки, вынужден будет установить у себя такую же версию градла. Неудобно. Но градло спешит на помощь ! Можно добавить в build.gradle следующее:
task wrapper(type: Wrapper) { gradleVersion = '2.0' // Желаемая версия } |
и после этого выполнить команду gradle wrapper
, которая сгенерирует следующие файлы:
gradlew gradlew.bat gradle/wrapper/ gradle-wrapper.jar gradle-wrapper.properties |
Эти файлы нужно закоммитить (да-да, джарник тоже, но он крошечный). И теперь чтобы собрать проект, достаточно вместо gradle
использовать gradlew
:
gradlew build |
Враппер сам скачает нужную версию градла, поместит её в .gradle
-кеш и использует её для сборки. Таким образом, пользователю, скачавшему ваш репозиторий, вообще ничего не нужно делать, кроме запуска bat-файла (или shell-скрипта в не-Windows системах) ! Вот такой вот best practice. Разве не блистательно ?
This guide covers a process in Windows with TortoiseHG as mercurial client.
Install git, generate ssh keys
- Install git
- Sign up for github
- Generate ssh keys and store it into ~/.ssh
- Upload ssh keys to your github account
- Create git repo
Install hg-git extension
- Install python3 and set up PATH to python bin directory
- Clone hg-git plugin source code
- Add full path to hg-git source code to ~/mercurial.ini
[extensions] hggit = c:\Users\Igor\hg_plugins\hg-git\hggit
Without trailing slash !
Configure mercurial’s putty to use git ssh key
- Generate key pair file for putty (import existing keys and export as ppk)
using puttygen tool - Add ssh key parameter to
[ui]
section of ~/mercurial.ini[ui] ssh=TortoisePlink.exe -i "c:\Users\Igor\.ssh\elwood.ppk"
Push changesets to it!
- Run commands inside your hg repo:
$ hg bookmark -r default master # make a bookmark of master for default, so a ref gets created $ hg push git+ssh://git@github.com:elw00d/consoleframework.git
- If your mercurial commits are not recognized in github as yours, check the email of your git ssh key
and email of committers. They should be equal to allow github detect that it was you.
Congratulations, you now have a mirror of your mercurial repo !
Support your mirror in actual state
If you have pulled some changesets from another hg repo, you may to want to push it to git. But your master bookmark needs to be “fast-forwarded”. To do this, use a command
$hg bookmark master |
After that you can push to git repo again. Btw, usually if you run hg pull && hg update, bookmark will be updated automatically.
0