Показаны сообщения с ярлыком Maven. Показать все сообщения
Показаны сообщения с ярлыком Maven. Показать все сообщения

вторник, июля 1

"Лишние" зависимости SLF4J

При запуске тестов в лог выходит нечто подобное:

Configuring TestNG with: TestNG652Configurator
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/.../.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../.m2/repository/org/slf4j/slf4j-jdk14/1.7.5/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../.m2/repository/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See [url]http://www.slf4j.org/codes.html#multiple_bindings[/url] for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]


В этом случае, согласно документации, нужно просто найти и исключить "лишние" зависимости.

У меня ими оказались org.slf4j:slf4j-jdk14 и ch.qos.logback:logback-classic - у обеих библиотек была зависимость уровня runtime.
Удалил так: http://pastebin.com/uDeUnp7m

понедельник, июля 8

PowerMock(+Mockito) +TestNG и мокинг статических классов/методов

На хабре уже была статья с примерами использования PowerMock, но в ней не хватает такого описания, как мокирование статических методов как самостоятельных "единиц" в классе, так и в гибридном использовании, когда часть статических методов у класса мокируются, а часть вызываются реально. Попробую исправить эту нишу.

полная статья на хабре

четверг, декабря 27

maven dependency. include scope

в документации к maven-dependency-plugin для copy-dependencies описан параметр includeScope, позволяющий указать какие зависимости копировать. но параметр принимает только одно указание scope. А что делать, если требуется указать несколько?
Всё просто - указывает несколько раз параметр includeScope.

например так:
<plugin>
 <artifactId>maven-dependency-plugin</artifactId>
 <executions>
  <execution>
   <id>copy-dependencies</id>
   <goals><goal>copy-dependencies</goal></goals>
   <configuration>
    <includeScope>system</includeScope>
    <includeScope>compile</includeScope>
   </configuration>
  </execution>
 </executions>
</plugin>

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

воскресенье, июля 4

Maven2 и несколько серверов для WAR-архива. часть 1: работа с зависимостями

Предистория:
С недавних пор решил перебраться с Ant на Maven. Причины? они просты - в Maven неплохо реализована работа с зависимостями (которую я активно использую в Eclipse), но мне было неудобно каждый раз выискивать и копировать эти зависимости ручками на сервер (что тестовый, что "боевой"). В итоге было решено перебраться полностью. А там, где возможностей не хватает, то использовать Antrun плагин, позволяющий использовать ant-скрипты.

Итак, лирика закончилась. Приступим к реализации цели поста.

Имеется исходная задача:
1) набор зависимостей для проекта (здесь и далее подразумевается разработка WAR-архива)
2) "боевой" удалённый сервер
3) тестовый удалённый сервер (отличается от "боевого" настройками для отладки)
4) на серверах установлен Tomcat6 с настроенной поддержкой shared-lib


Первая проблема, с которой я столкнулся, была возможность указания в конфигурации единого правила для копирования зависимостей на разные сервера "по запросу".

Для определения dependency-библиотек, которые будут копироваться в shared-каталог tomcat, будем использовать указание scope как provided (подробнее про scope читать на русском тут)

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

  • профиль "development" - указываем свойства, специфичные для сервера разработки, такие как пути и логины/пароли
  • профиль "production" - указываем свойства, специфичные для "боевого" сервера (всё те же пути и логины/пароли)
  • профиль "dependency" - в этом профиле описываем плагины (и их работу), отвечающие за копирование зависимостей на выбранный сервер
пример профиля "development" (для профиля "production" подставляются другие значения свойств):
<profile>
 <id>development</id>
 <properties>
  <hostname>servername.dev</hostname>
  <ssh.host>${hostname}</ssh.host>
  <ssh.username>логин</ssh.username>
  <ssh.password>пароль</ssh.password>
  <ssh.tomcat.lib.shared>/srv/tomcat/shared/lib</ssh.tomcat.lib.shared>
 </properties>
</profile>

Теперь перейдём к самому "сложному" - копированию зависимостей на сервер.
для этого потребуется 2 шага - сбор зависимостей и, собственно, само их копирование.

Для сбора зависимостей, воспользуемся плагином maven-dependency-plugin, для которого укажем некоторые нюансы его работы:
<plugin>
 <artifactId>maven-dependency-plugin</artifactId>
 <version>2.1</version>
 <executions>
  <execution>
   <id>10-copy-dependencies</id>
   <phase>process-resources</phase>
   <goals><goal>copy-dependencies</goal></goals>
   <configuration>
    <IncludeScope>provided</IncludeScope>
    <outputDirectory>${project.build.directory}/dependency</outputDirectory>
    <overWriteReleases>false</overWriteReleases>
    <overWriteSnapshots>false</overWriteSnapshots>
    <overWriteIfNewer>true</overWriteIfNewer>
   </configuration>
  </execution>
 </executions>
</plugin>

Кратко поясню, что здесь написано.
1) указано выполнение плагина с моими настройками на этапе работы с ресурсами (process-resources) проекта. подробнее про Lifecicle проекта можно глянуть тут
2) указываем, какие (IncludeScope) и куда (outputDirectory), а так же режим копирования

Теперь перейдём к шагу копирования полученных зависимостей на удалённый сервер. Для этого воспользуемся ant задачей scp
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-antrun-plugin</artifactId>
 <version>1.4</version>
 <executions>
  <execution>
   <id>90-antrun-copy-dependencies</id>
   <phase>process-resources</phase>
   <goals><goal>run</goal></goals>
   <configuration>
    <tasks>
     <scp todir="${ssh.username}@${ssh.host}:${ssh.tomcat.lib.shared}" 
      password="${ssh.password}">
      <fileset dir="target/dependency" />
     </scp>
    </tasks>
   </configuration>
  </execution>
 </executions>
 <dependencies>
  <dependency>
   <groupId>ant</groupId>
   <artifactId>ant-jsch</artifactId>
   <version>1.6.5</version>
  </dependency>
  <dependency>
   <groupId>com.jcraft</groupId>
   <artifactId>jsch</artifactId>
   <version>0.1.42</version>
  </dependency>
 </dependencies>
</plugin>

Кратко поясню, что здесь написано:
1) Указано выполнение плагина maven-antrun-plugin с моими настройками на этапе работы с ресурсами (process-resources) проекта
2) Для выполнения плагина подключены необходимые зависиимости, доступные только на этапе работы плагина (требуются для scp-задачи)

Теперь описанные выше два плагина мы добавляем в профиль "dependency" следующим образом:
<profile>
 <id>copy-dependency</id>
 <build>
  <finalName>${hostname}</finalName>
  <plugins>
   <plugin>
    <artifactId>maven-dependency-plugin</artifactId>
    ...
   </plugin>
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-antrun-plugin</artifactId>
     ...
   </plugin>
  </plugins>
 </build>
</profile>

На этом конфигурирование Maven для проекта закончилось.

Следующий шаг - настройка запуска сборок в eclipse для проекта maven.
воспользуемся плагином m2eclipse и в диалоге Run>Run configurations... создадим 2 конфигурации:




В профиле мы указываем сразу 2 профиля - один (например "development") используется для предоставления свойств, а второй ("dependency") реализует процедуру копирования зависимостей на сервер согласно указанных свойств
Так же мы указываем 2 шага выполнения Maven - clean (очистка от предыдущей сборки) и работу с ресурсами (process-resources).

Итог:
создавая и комбинируя различные профили, можно добиться практически такой же гибкости как у Ant, при этом Maven "заставляет" нас придерживаться строгой структуры каталогов (что тоже можно немного изменить) и последовательностей сборки проекта.

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

четверг, февраля 4

NetBeans+Maven+библиотеки

Использование Maven позволяет делать многое при разработке проекта. Об этом писалось уже не раз на просторах интернета. Я же напишу небольшую толику, чего я не нашел на русскоязычных просторах - про добавление своих JAR-библиотек в среде NetBeans IDE в Maven-проект.

Пример демонстрирует использование внешней библиотеки NCSO.jar для подключения к Lotus Domino через DIIOP. Проект создаём в NetBeans 6.8

итак, поехали


Создаём простой Maven-проект (для примера его будет достаточно :) )



Теперь добавляем в проект завимость на внешнюю библиотеку NCSO.jar. Так как этой библиотеки нет в репозитариях, то просто указываем сами группу, артифакт и версию библиотеки. В данном случае, я использую библиотеку, взятую с сервера Lotus Domino версии 8.5.1


Теперь можно загрузить сам jar-файл в локальный репозитарий. Для этого в контексном меню у зависимости выберем пункт "Manually install artifact" и укажем путь до библиотеки. По завершению инсталяции, данная библиотека будет добавлена в локальный репозитарий и может быть использована в последующих проектах без дополнительной инсталяции.





ЗЫ: посмотреть все скриншоты можно в альбоме "Blogspot:002", а скачать архив проекта на iFolder