В последние месяцы я разработал Java-проект, инструмент для экспериментального анализа из командной строки.Поскольку у меня нет специалиста по CS в фоновом режиме (вместо этого математика / инженерия), я имел удовольствие сражаться и изучать такие понятия, как управление проектами и POM, контроль версий (SVN) и сценарии сборки (ANT).Причина, по которой я описываю это, состоит в том, чтобы изобразить тот факт, что большинство этих концепций не приходят ко мне естественным образом, в отличие от алгоритмов и формул (я думаю, можно сказать, что я научился быть « кодером »)."не" программист", если такое различие является действительным / принятым).
При этом я сумел заставить вещи работать по большей части, однако довольно неполно / уродливо враз.Поскольку я хотел бы учиться и совершенствоваться по пути, я подумал спросить здесь о SO.Файл ANT, который я использую сегодня и который с течением времени создается с некоторой помощью, прилагается ниже.
Учитывая ситуацию, я хотел бы ...:
Вопрос 1: ... добавить контроль версий в некоторой степени, поэтому, когда я поставляю программное обеспечение какJAR-файл для пользователей по всему миру, и они, и я можем отслеживать потенциальные проблемы и разработки.Номер версии, прикрепленный к имени файла JAR (например, prog-0.1.5.jar), наряду с каким-либо выводом пользователю во время выполнения, будет идеальным.Мне сказали, что это возможно через ANT, но мне пока не повезло.Любые советы или предложения?
Я также получил следующий фрагмент кода для этой цели, но я не уверен, почему / как он будет работать в моем проекте, поскольку я не объявил эти атрибуты / свойства ...
<svn>
<status path="."
lastChangedRevisionProperty="someproject.build" />
</svn>
РЕДАКТИРОВАТЬ: Просто чтобы прояснить мои длинные вопросы, я хотел бы стандартизировать управление версиями в моем проекте.Возможно, я неправильно использовал этот термин, но сейчас осуществляется контроль версий:
- Я регулярно выполняю коммиты на сервер SVN для отслеживания изменений (а также для создания резервных копий)
- Я вручную пытаюсь отслеживать различные версии программного обеспечения
Чтобы привести пример того, чего я хочу достичь в отношении управления версиями:
- Я бынравится избегать ручной нумерации версий;это просто так подвержено ошибкам ...
- Я хотел бы отслеживать различные сборки, по крайней мере локально, используя их номера версий, так что я всегда имею более старую сборку, если мне понадобитсяисследовать старую сборку.(Теперь я делаю
ant dist-clean; ant dist для новых сборок, которые просто перезаписывают старые JAR-файлы) - Было бы предпочтительным, если бы номер версии мог быть включен в сборку, поэтому содержательная строка (например, «Вы сейчас запускаете My_Awesome_software»).v: 0.1.3 ") при запуске JAR
- Для достижения вышеупомянутого с SVN в качестве отслеживания версии и ANT в качестве инструмента сборки.Я не уверен, могу ли я изменить отслеживание версий на нашем сервере, и Maven просто не подходит на данном этапе.Кажется, это большая проблема для изучения среднего уровня, чем какие бы то ни было преимущества ...
Вопрос 2: ... изучите юнит-тестирование.Я много читал о модульном тестировании, являющемся святым Граалем современного программирования, и у меня есть некоторые отдаленные воспоминания о JUnit из университета несколько лет назад.Я понимаю, что в идеальной среде разработки программного обеспечения модульное тестирование является абсолютно критическим, однако я понятия не имею, как следует / можно проводить модульные тесты в моем случае;где программное обеспечение имеет минимальный пользовательский интерфейс (файл параметров и несколько необязательных флагов во время выполнения) и длительное (читай: часы) время выполнения в связи с анализом.
Учитывая ситуацию, все еще считается плохой практикой не проводить модульные тесты, если это так, как мне следует рассуждать, когда я структурирую свои тесты?
Мне кажется, что юнит-тесты, как правило, в несколько раз больше и выполняются даже дольше, чем реальное программное обеспечение, если я пытаюсь протестировать большинство функций в программном обеспечении.
выводы: Я изучал эту концепцию нумерации версий с помощью ANT, я кратко обобщу свои выводы для других, кто может столкнуться с тем же вопросом:
Создайте файл свойств как @Kevin Stembridge, упомянутый ниже, например, build.properties. Моя выглядит так:
micro.version = 5
build.number = 5
major.version = 0
minor.version = 0
Импортировать свойства из этого файла с: <property file="project-version.properties"/>
Согласуйте желаемую схему нумерации с именем банки в теге банки. Смотрите код ниже.
Модульное тестирование необходимо, однако сложно для такого проекта, как мой. Я буду смотреть на это по мере развития проекта.
Спасибо всем, кто как-то помог, я выбираю ответ Кевина как принятый, поскольку он единственный, который оказал непосредственное влияние на мое решение здесь.
<target name="dist" depends="compile,static" description="Compiles and builds jar files">
<mkdir dir="${dist}"/>
<buildnumber file="project-version.properties"/>
<property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/>
<svn>
<status path="."
lastChangedRevisionProperty="rev.number" />
<info target="." />
</svn>
<jar basedir="${build}"
destfile="${dist}/fever-${version.number}-rev${rev.number}.jar"
includes="**/*" />
</target>