среда, 2 декабря 2009 г.

Maven - Использование библиотек, которых нет в официальных репозитариях

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

Когда я переводил на Maven свой первый проект я столкнулся с большой проблемой - а где взять библиотеки, которые не представлены в официальном maven репозитарии, но от которых зависит проект? Честно признаться в первый момент меня этот вопрос поставил в тупик и пришлось призвать на помощь накомых maven-оводов.

Сначала немного теории. Для разрешения зависимостей в Maven используются репозитарии зависимостей, где размещены собранные версии различных библиотек и приложений. При этом в большинстве репозитариев все эти бобилиотеки содержат специальную мета-информацию о своих зависимостях, в формате понятно Maven. Поэтому вы можете в своем проекте сказать что ваше приложение использует API сервера jetty и Maven при сборке автоматическе выкачает сам jetty указанной версии и необходимые для его работы зависимоcти.

Maven репозитариев достаточно много, перечислю только несколько наиболее популярных:

Самым большим конечно яляется основной репозитарий, там собрана огромная коллекция Java библиотек, она регуряно обновляется и имеет метаинформацию. Но там есть не все. В таких случая нужную библиотеку иногда можно найти в каком-то специализированном репозитарии, тут вам на помощь придет MVNRepository, Maven Search или другой поисковик Maven артифактов, таких сайтов сейчас не один десяток.

И все-же бывают случаи когда нужной библиотеки в репозитариях нет или вы используете какие либо библиотеки собственной разработки. Тут вам на помощь придет локальный и проектный/корпоративный репозитарий. Разберемся что это такое.

Локальный репозитарий
Такой репозитарий создается на локальной машине с целью кеширования артифактов, выкачиваемых из вышестоящих репозитариев. Поэтому первая сборка Maven проекта идет так долго - необходимо скачать зависимости проекта из внешнего репозитария, а потом и зависимости зависимостей. Таким образом локальный репозитарий быстро разрастается до размеров в несколько гигабайт. Полезно знать где он находится и как перенести его на другой диск.

Настройки репозитария находятся в файле settings.xml, который хранится в домашней папке пользователя ($HOME/.m2 для Linux и $USER_HOME/.m2 для Windows.
Путь к локальному репозитарию задается переменной localRepository и по умолчанию репозитарий находится в папке .m2

Для установки собранных артифактов в локальный репозитарий необходимо выполнить команду mvn install. Для установки в локальный репозитарий кастомных библиотек необходимо использовать расширенный синтаксис поканды install:

mvn install:install-file -DgroupId=com.oracle -DartifactId=ojdbc -Dversion=11.1.0.7.0 -Dpackaging=jar -Dfile=ojdbc6.jar

Тут мы задаем группу, к которой будет относиться библитека, её идентифкатор, версиию и собственно сам файл.

Чтобы указать эту библиотеку в заивисмостях необходимо написать следующее:


<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>11.1.0.7.0</version>
</dependency>


Недостатки:
  • Репозитарий локален, другие разработчики не имею к нему доступ
  • На другом компьютере использовать нельзя
  • Проблемы на серверах автосборки
  • Нет централизованного места для хранения стабильных версий компонентов проекта
Плюсы:
  • Не требует настройки, администрирования
  • Прост в использовании

На одном из проектов мы некоторое время использовали локальные репозитарии для хранения custom-артифактов, в svn-репозитарии у нас была отдельная папка extlib и bat-файл, который при запуске деплоил все эти библиотеки в локальный репозитарий. Но проблемы с серверами автосборки и необходимость писать письмо на команду "Запустите batник перед сборкой" после каждого обновления библиотеки пересилило лень и мы развернули проектный Maven репозитарий.

Проектный / корпоративный репозитарий

В определенный момент функционал локального репозитария перестает устраивать и начинаются поиски более функционального решения. Тут ваиантов несколько:
  • расшарить папку с репозитарием, и настроить maven на остальных компьютерах на использование этого расшаренного репозитария
  • развернуть свой Maven репозитарий

В первом случае нам нужно будет настраивать Maven на всех машинах участвующих в сборке проекта.
Во втором случае мы разворачиваем свой репозитарий, добавляем его в pom.xml проекта и с этого момента при сборке проекта на любой машине - maven в поисках артифактов будет заглядывать и в наш репозитарий.

Сейчас существует большое количество продуктов (как закрытых и клатных, так и Open Source), позволяющих развернуть свой Maven репозитарий. Приведу ссылки на некоторые: Apache Archiva, Artifactory, Nexus и другие.
Сейчас я не буду описывать настройку этих продуктов, скажу только что на развертывание Archiva я потрали часа 3.

Для того чтобы задеплоить кстомную библитоеку в репозитарий необходмо будет выполнить следующую команду:

mvn deploy:deploy-file -DgroupId=com.oracle -DartifactId=ojdbc -Dversion=11.1.0.7.0 -Dpackaging=jar -Dfile=ojdbc6.jar -DrepositoryId=archiva -Durl=http://mavenrep:8889/archiva/repository/oracle

Здесь мы указываем:
  • Группу библиотеки
  • Её идентификатор
  • Версию
  • Расположение на диске
  • Адрес репозитария

Для использования в зависимостях необходимо подлючить этот репозитарий к проекту, для этого добавляем:


<repositories>
<repository>
<id>oracle</id>
<url>http://mavenrep:8889/archiva/repository/oracle</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>


После этого декларация зависимости не будет отличаться от предыдущего примера.

Maven репозитарии кроме всего проечего предлагают и некоторые дополнительные функции:
  • Прокси для вышестоящих репозитариев
  • Поиск по репозитарию
  • Права доступа
  • и другие

Заключение:

Лучше конечно обходиться без зависимостей от нестандартных библиотек, но такой вариант почти нереален. Поэтому для хранения custom библиотек в проектах, использующих Maven для сборки, лучше развернуть свой собственный репозитарий. В последствии вы сможете его использовать и для хранения релиз-версий своих артифактов, а потом возможно он станет репозитарием всей компании.

И один раз настроив репозитарий - вы решаете большинство проблем с управлением зависимостей и можете сосредоточиться на разработке.

среда, 25 ноября 2009 г.

Что нового в JDK 7 - Часть первая

На днях завершилась конференция Devoxx.com, где Mark Reinhold официально объявил - замыкания (closures) будут в JDK 7. Для многих замыкания были очень важным нововведением - с одной стороны они должны значительно расширить выразительность языка и привнести некоторую долю функционального программирования в Java. В вот с другой стороны это усложнит язык - и не все разработчики смогут в полной мере использовать эти возможности.

Но замыкания это отдельная тема для отдельной статьи, сейчас могу предложить только оригинальную статью Closures in JDK 7. Я постараюсь написать об этом позже.

А теперь вернемся к теме - А что-же еще нового в JDK 7, которая должна выйти в сентябре 2010 года?

Намнем с 7ми нововедений в языке, которые были реализованы в рамках проекта Coin (это перевод статьи New language features in Java 7):

вторник, 17 ноября 2009 г.

Что почитать Java разработчику - Блог №1 - Geek Explains

Я начинаю новую верию постов, в которых буду давать краткие аннонтации лучшим, на мой взгляд, блогам о Java-разработке.
И сегодня в первом выпуске я хочу вам представить блог Geek Explains.

Язык: английский
Автор: An Indian, a Software Engineer, a Web Addict, and a Blogger.
Тематика: Различные тонкие моменты и особенности Java
Частота обновления: Несколько раз в месяц
Оценка: 10/10

Практически уникальный блог, выделяется на фоне других именно своей тематикой. Автор редко пишет о новых технологиях, конференциях или теоретических вещах. Основной материал блога составляют рассказы о ситуациях в Java с которыми мы регулярно сталкиваемся на работе, но обычно откладываем на потом или просто забиваем. Например:

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

Что нового будет в Maven 3

Apache Maven — фреймворк, сборщик программных проектов, специфицированных на XML-языке POM (en).

Управление зависимостями является одной из самых сильных сторон этого фреймворка. В отличие от Ant, сборка проекта в maven описывается декларативно а не императивно (командами). В Maven большинство операций стандартизировано, а большинство нестандартных задач решаются с помощью плагинов.

Сейчас Maven находится в стадии активной разработки. Стабильной версией является вертка 2.2, в разработке находится версия 3.

Одной из главных особенностей версии 3 будет полная обратная совместимость с проектными файлами написанными для версии 2.x. Хорошо это или плохо - сложно сказать. С одной стороны это значительно ускорит миграцию старых пользователей на новую версию, с другой требует больших трудозатрат от разработчиков. Для облегчения жизни при поддержании совместимости разработчики написали большое количество Unit Testов, покрывающих большую часть функционала. Совместимы будут не только файлы сборки, но и плагины.

Еще одной интересной особенностью в 3ей версии будет так называемый Polyglot Maven. Этот подпроект направлен на значительное расширение возможностей при написании и интерпритации pom файлов. Например теперь pom-файлы можно писать с использованием Groovy. При этом это не просто еще один вариант записи нотации - в таком pom файле можно использовать функции языка Groovy для манипуляции данными. Создана специальная утилита, позволяющая конвертировать polyglot pom в привычное xml описание. Мне пока сложно представить где эта возможность найдет свое применение, но она явно позволит вносить больше динамики в файлы сборки. Например извлечение параметров сборки из БД или других источников.

Embedded maven - Maven уже перерос время когда он был внешним средством для сборки проекта. Сейчас Maven уже интегрирован в Eclipse с помощью плагина m2eclipse, и как мне известно в NetBeans используют версию 3 для реализации поддержки Maven. При этом главной проблемой стала неподготовленность API maven для использования в качестве библиотеки. Оно было достаточно сложным и запутанным. В версии 3 этому уделили отдельное внимание. Вместе с полной обратной совместимостью это дало неожиданный эффект - уже сейчас плагины интеграции maven в основные IDE используют 3ью версию как встроенную библиотеку. Но при этом API еще находится в стадии активной разработки и не подвергалось заморозке.

Оптимизация производительности - тут все понятно. Оптимизации потребления CPU, дисковых операций, кеширования. В результате обещают повышение скорости сборки на 50-200%.

Maven Shell - специальный вариант работы Maven, значительно расширяющий обычную CLI версию. Обещают что это будет значительно удобнее и производительнее чем обычные сборки из командной строки.

Ну и самое главное - вместе с выходом 3.0 GA нам обещают полностью обновленную книгу: Maven: The Definitive Guide.

Если у кого-то возникло желание уже сейчас испробовать Maven 3, то для вас готова свежая 3ья альфа. Разработчики призывают к активному тестированию и обещают оперативно реагировать на отзывы, отчеты об ошибках и патчи.

ps: В основе статьи лежит: Maven 3.0-alpha-3 Released!

понедельник, 16 ноября 2009 г.

Виды сертификации Java

Сертификация - это один из способов документального подтверждения вашего опыта в той или иной области.

Для Java существует несколько основных направлений сертификации:
       
  • От компании SUN - на знание самого языка и технологий
  •    
  • От компаний Oracle, IBM, RedHat - на знание конкретного стека технологий, разрабатываемых этими компаниями (например SOA Fundamentals от IBM или JBoss jBPM от RedHat)
  •    
  • От сторонних компаний - на знание конкретных продуктов или технологий .


    И полный список этих сертификаций очень большой, но нужны-ли нам эти все сертификаты, а если нужны - с чего начать?


    Что такое сертификация?


    Сертификация - это подтверждение фаших профессиональных знаний и опыта в той или иной области. Формы проведения сертификации могут быть различными:
         
    • Удаленный экзамен
    •    
    • Тестирование
    •    
    • Практическое задание
    •    
    • Личное собеседование
    •    
    • Теоретические вопросы

    Также сертифкация может состоять из нескольких этапов или заданий. Обычно сертификации соответствуют профессиональному развитию человека - начиная с самых основ языка или технологии и заканчивая экспертным уровнем понимания архитектуры решения. Такие сертификации расчитаны на прохождение в течении нескольких лет.
    Для чего это нужно?