Comments 23
Однако с Maven не всё так радужно.
Вы правильно указали на необходимость поддерживаться свой Nexus, т.к. внешние репозитории могут внезапно отваливаться или исчезать или исчезать интернет.
Ещё для меня загадка как собрать и протестировать проект под разными JDK.
Лютую ненависть вызывает этап генерации кода. Почему-то, все считают своим долгом что-нибудь, неважно что, на этом этапе сгенерировать.
Вот с разрешением зависимостей Maven справляется отлично.
Сейчас трогаю связку Ant+Ivy. Но пока приходится плясать с бубном.
Вы правильно указали на необходимость поддерживаться свой Nexus, т.к. внешние репозитории могут внезапно отваливаться или исчезать или исчезать интернет.
Ещё для меня загадка как собрать и протестировать проект под разными JDK.
Лютую ненависть вызывает этап генерации кода. Почему-то, все считают своим долгом что-нибудь, неважно что, на этом этапе сгенерировать.
Вот с разрешением зависимостей Maven справляется отлично.
Сейчас трогаю связку Ant+Ivy. Но пока приходится плясать с бубном.
0
Все просто, подключаем плагин:
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, так что надо один раз все настроить…
<!-- Настройки компиляции -->
<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, так что надо один раз все настроить…
+1
Ну это ж шевелиться надо, 2 кнопки нажимать. Или скрипт рядом ваять. Что ни говорите, а Ант универсальней.
С другой стороны при разрастании проекта, Ант-скрипты становятся, мягко говоря, трудно сопровождаемыми.
С другой стороны при разрастании проекта, Ант-скрипты становятся, мягко говоря, трудно сопровождаемыми.
0
Ну их же надо переключать.
Поясню. У меня есть библиотека, которая ант-скриптом собирается и тестируется под 2мя JDK, затем складывается в один архив с исходниками и документацией. Все это делается одной кнопкой.
Поясню. У меня есть библиотека, которая ант-скриптом собирается и тестируется под 2мя JDK, затем складывается в один архив с исходниками и документацией. Все это делается одной кнопкой.
0
Тестировать и собирать можно под разными jdk, в сборку же попадает сборка из одной jdk. Надо просто попробовать настроить для своих целей сборку. У нас не было такой необходимости.
Тесты запускаются под разными JDK? Есть различия в поведении или просто проверяется возможность сборки под конкретной 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>
0
Можно указать список необходимых для активации профилей:
Также можно задать профили через настройки Мавена в файле settings.xml
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
0
А как дела обстоят в случае, если структура проекта иная и ее нельзя изменить? С maven идея сейчас дружит хорошо.
0
Вообще gradle позволяет делать кастомные проекты (не используя java/war/ear плагины), но при этом многие фишки, например автоматичексий запуск тестов, чекстайла и т.п. придется делать вручную. Если под структурой проекта подразумевается просто расположение исходников и ресурсов, то такие вещи можно подкрутить при помощи source set'ов.
0
Коллеги, подскажите старику, далекому от джавы — в терминологии maven что есть nexus? Это какой-то штатный локальный репозиторий, сторонний продукт для создания локальных репозиториев, какая-то настройка мавена для создания локального репозитория? Гугль выдает странное.
0
Менеджер репозиториев
www.sonatype.org/nexus/
www.sonatype.org/nexus/
+1
UFO just landed and posted this here
Makefile ?:)
0
Насколько знаю для C# используют NAnt или MSBuild
0
В С++ используются makefile'ы, конкретно тулчейн 'autotools'. Когда запускается скрипт './configure' (или 'configure.exe'), система анализируется на предмет установленных библиотек, их пути прописываются в общий .h файл, передаются линкеру и компилятору.
Откуда в системе библиотеки возьмутся — это отдельный больной вопрос. Для nix и osx есть сстему управления зависимостями. Например 'port install GIMP' при установке проинспектирует зависимости и поставит все библиотеки нужных версий, от которых программа зависит — после чего уже соберет сам GIMP. «Общего решения» типа maven, насколько я знаю для C++ не существует.
На практике стараются управление версиями спихнуть на VCS: необходимые версии библиотеки помещаются в локальные репозитории и делается простенький скрипт на python/ruby/perl который устанавливает необходимые переменные окружения для корректной сборки и линковки. Нужные версии библиотек фиксируются через метки в системе контроля версий.
Откуда в системе библиотеки возьмутся — это отдельный больной вопрос. Для nix и osx есть сстему управления зависимостями. Например 'port install GIMP' при установке проинспектирует зависимости и поставит все библиотеки нужных версий, от которых программа зависит — после чего уже соберет сам GIMP. «Общего решения» типа maven, насколько я знаю для C++ не существует.
На практике стараются управление версиями спихнуть на VCS: необходимые версии библиотеки помещаются в локальные репозитории и делается простенький скрипт на python/ruby/perl который устанавливает необходимые переменные окружения для корректной сборки и линковки. Нужные версии библиотек фиксируются через метки в системе контроля версий.
+1
UFO just landed and posted this here
Помимо скриптов configure есть еще CMake, которая умеет делать то же самое + обладает доп. фичами, например содержит в себе кучу модулей для поиска в системе и подключения популярных библиотек, умеет генерировать не только разные makefile, но и проекты для разных IDE (VisualStudio, Code::Blocks, Eclipse CDT). ИМХО освоить ее проще, чем autotools, и проще использовать под windows.
0
перестал читать статью после слова репозитарий
-3
Спасибо за статью. Мы тоже используем maven для организации CI-цикла, вполне довольны. Более подробно свой опыт описывал у себя в блоге – Маленький Билд и его друзья
+1
Sign up to leave a comment.
Как мы делали сборки