Как мы делали сборки

[kefirfromperm]

Однако с Maven не всё так радужно.

Вы правильно указали на необходимость поддерживаться свой Nexus, т.к. внешние репозитории могут внезапно отваливаться или исчезать или исчезать интернет.

Ещё для меня загадка как собрать и протестировать проект под разными JDK.

Лютую ненависть вызывает этап генерации кода. Почему-то, все считают своим долгом что-нибудь, неважно что, на этом этапе сгенерировать.

Вот с разрешением зависимостей Maven справляется отлично.

Сейчас трогаю связку Ant+Ivy. Но пока приходится плясать с бубном.

[VaiMR]

Все просто, подключаем плагин:

      <!-- Настройки компиляции -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <encoding>cp1251</encoding>
          <source_>${jdk.version}</source_>
          <target>${jdk.version}</target>
        </configuration>
      </plugin>

source_ — потому что парсер закрывает тег.

и ставим jdk 1.5. Можно использовать properties-файл. К примеру. jdk я переключаю просто:

1. Ставлю несколько jdk в разные папки: jdk_5, jdk_6 и пустую jdk
2. Создаю два bat-файла с содержимым:
rmdir jdk
mklink /D jdk jdk_5
и
rmdir jdk
mklink /D jdk jdk_6

Можно переключаться. В linux еще проще. Одну проблему решить не смог с дефолтным jre, его файлы попадают в system32 и их никакими ссылками не заменить, да еще и в реестре прописывается. Думаю, тоже вопрос решаем.

В заведении Nexus-a проблем нет, если проект достаточно велик.

«Почему-то, все считают своим долгом...» — сборка зависит полностью от pom, так что надо один раз все настроить…

[kefirfromperm]

Ну это ж шевелиться надо, 2 кнопки нажимать. Или скрипт рядом ваять. Что ни говорите, а Ант универсальней.

С другой стороны при разрастании проекта, Ант-скрипты становятся, мягко говоря, трудно сопровождаемыми.

[VaiMR]

Мы в большинстве своем собираем под jdk 1.6, очень редко надо собирать под jdk 1.5, поэтому переключить jdk батником не составляет труда:

[Terentich]

Для сборки под разные версии JDK можно использовать профили.

[kefirfromperm]

Ну их же надо переключать.

Поясню. У меня есть библиотека, которая ант-скриптом собирается и тестируется под 2мя JDK, затем складывается в один архив с исходниками и документацией. Все это делается одной кнопкой.

[VaiMR]

Тестировать и собирать можно под разными jdk, в сборку же попадает сборка из одной jdk. Надо просто попробовать настроить для своих целей сборку. У нас не было такой необходимости.

Тесты запускаются под разными JDK? Есть различия в поведении или просто проверяется возможность сборки под конкретной jdk?

У нас есть модули, которые должны иметь возможность собираться под конкретной jdk, поэтому при сборке делается проверка такой возможности:

 <!--Проверяем, что можно собрать модуль под определенной jdk-->
      <plugin>
        <groupId>org.jvnet</groupId>
        <artifactId>animal-sniffer</artifactId>
        <version>1.2</version>
        <executions>
          <execution>
            <id>check-java-version</id>
            <phase>compile</phase>
            <goals>
              <goal>check</goal>
            </goals>
            <configuration>
              <signature>
                <groupId>org.jvnet.animal-sniffer</groupId>
                <artifactId>java1.5</artifactId>
                <version>1.0</version>
              </signature>
            </configuration>
          </execution>
        </executions>
      </plugin>

[Terentich]

Можно указать список необходимых для активации профилей:

Details on profile activation

Profiles can be explicitly specified using the -P CLI option.

This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.

mvn groupId:artifactId:goal -P profile-1,profile-2

Также можно задать профили через настройки Мавена в файле settings.xml

[Losted]

Мы в новом проекте вместо ant+ivy решили начать с Gradle, На текущий момент довольны — зависимости разрешаются, структура проекта специфицирована, однако груви позволяет ее легко «гнуть» в нужную сторону. К недостаткам можно отнести бестолковый (пока?) плагин для идеи.

[VaiMR]

А как дела обстоят в случае, если структура проекта иная и ее нельзя изменить? С maven идея сейчас дружит хорошо.

[Losted]

Вообще gradle позволяет делать кастомные проекты (не используя java/war/ear плагины), но при этом многие фишки, например автоматичексий запуск тестов, чекстайла и т.п. придется делать вручную. Если под структурой проекта подразумевается просто расположение исходников и ресурсов, то такие вещи можно подкрутить при помощи source set'ов.

[grigoryvp]

Коллеги, подскажите старику, далекому от джавы — в терминологии maven что есть nexus? Это какой-то штатный локальный репозиторий, сторонний продукт для создания локальных репозиториев, какая-то настройка мавена для создания локального репозитория? Гугль выдает странное.

[kefirfromperm]

Менеджер репозиториев
www.sonatype.org/nexus/

[vanxant]

Makefile ?:)

[TheDimasig]

Насколько знаю для C# используют NAnt или MSBuild

[grigoryvp]

В С++ используются makefile'ы, конкретно тулчейн 'autotools'. Когда запускается скрипт './configure' (или 'configure.exe'), система анализируется на предмет установленных библиотек, их пути прописываются в общий .h файл, передаются линкеру и компилятору.

Откуда в системе библиотеки возьмутся — это отдельный больной вопрос. Для nix и osx есть сстему управления зависимостями. Например 'port install GIMP' при установке проинспектирует зависимости и поставит все библиотеки нужных версий, от которых программа зависит — после чего уже соберет сам GIMP. «Общего решения» типа maven, насколько я знаю для C++ не существует.

На практике стараются управление версиями спихнуть на VCS: необходимые версии библиотеки помещаются в локальные репозитории и делается простенький скрипт на python/ruby/perl который устанавливает необходимые переменные окружения для корректной сборки и линковки. Нужные версии библиотек фиксируются через метки в системе контроля версий.

[kosmonaFFFt]

Помимо скриптов configure есть еще CMake, которая умеет делать то же самое + обладает доп. фичами, например содержит в себе кучу модулей для поиска в системе и подключения популярных библиотек, умеет генерировать не только разные makefile, но и проекты для разных IDE (VisualStudio, Code::Blocks, Eclipse CDT). ИМХО освоить ее проще, чем autotools, и проще использовать под windows.

[wwwsevolod]

перестал читать статью после слова репозитарий

[denis_bazhenov]

Спасибо за статью. Мы тоже используем maven для организации CI-цикла, вполне довольны. Более подробно свой опыт описывал у себя в блоге – Маленький Билд и его друзья