Я таки решил попробовать что-нибудь написать в своем блоге, так что не ругайте сильно если что ;) Первую статью пишу про систему построения и управления Java-проектами Apache Maven 2. Это обзорная статья, если кому-то будет интересно – сделаю небольшой цикл уже с подробностями.

При разработке на ActionScript, как и на любом другом языке, возникает два вопроса: «В чем писать?» и «Чем собирать?». Если вы продвинутый разработчик, вы наверняка уже используете IntelliJ IDEA как IDE и maven как инструмент сборки. Данная статья показывает оптимальность этого решения и описывает процесс настройки рабочего окружения. Если вы не любите пиво (и не понимаете смысл этой фразы и на кого я только что кивнул) и не считаете себя ленивой скотиной, можете не тратить свое время.

Статья скорее искра, чем пошаговое руководство, тем более, посвящена EAP, поэтому если вы ну совсем ленивая скотина без капли риска, то ждите релиза :)

Ни для кого не секрет, что для слаженной работы команды, особенно в проектах управляемых по методологии Agile, важен эффективный обмен информацией между участниками. Для того, чтобы информационные потоки не разрушались под влиянием человеческого фактора, стандартные процедуры по управлению информацией автоматизируются. В данной статье рассмотрен пример технической инфраструктуры, использующейся сотрудниками компании ООО «Креатив Медиа» при разработке Web-проектов на платформе Java, например, в проекте социальной сети Campus.ru.

Более полугода назад была написана статья Разработка на Flex в IntellliJ IDEA с использованием maven — она была обзорной и писалась в самом начале использования означенных инструментов. Теперь же хочется резюмировать и рассмотреть все более подробно — в этой статье будет дан обзор текущей ситуации и тех плюшек flexmojos, аналога которым вы не найдете нигде более.

Про полезность подхода TDD (разработка через тестирование, test driven development) не слышал только ленивый или глухой. Но сегодня мы не будем обсуждать всю его полезность и красоту, а также проблемы и недостатки. Сегодня мы попробуем посмотреть, как разрабатывать unit-тесты для spring приложений. Также мы немного тронем ручное управление транзакциями в unit-тестах.

Уже давно я слышал об инструменте для автоматизации сборки проекта — Ant, но как-то не мог найти ему реального применения в проектах на PHP. Компилить вроде ничего не надо, внешние библиотеки вполне можно подключить через svn:externals, оставались только тесты, которые свободно выполнялись через $ phpunit AllTests.php, да перенос изменений на рабочий сервер (svn export + небольшой самописный скрипт). Даже достаточно хорошая статья об использовании ant в eclipse не подвигла меня на использование сего инструмента, да еще и build файлы писать не хотелось…

Вобщем все как всегда. Какая-то подобная штука вроде бы и не помешала бы, но все и так хорошо работало и лень было изучать псевдопомогающую технологию. Так было до тех пор, пока я не познакомился с Java…

После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

На просторах сети вообще и хабра в частности мне доселось видеть не один топик посвящённый Maven. И везде, где было обсуждение, возникали вопросы вида:

• Что даёт его использование в проекте типа X?
• Чем он лучше Ant/Make/sh?
• А что делать если я хочу использовать в проекте antlr/JAX-WS/XDoclet?

Я полагаю, что все эти вопросы происходят из незнания что на свете есть гугл недостаточного понимания что такое Maven и какой подход к решению задач build management он предлагает. Что в свою очередь растёт из недостаточного внимания, которое авторы статей уделяют идеям стоящим за xml-файлами и завораживающими консольными командами.

Разрабатывая веб-приложения с обилием JS, со временем сталкиваешься с необходимостью автоматизировать сборку и тестирование, а также построение различных отчетов, документации и т.п. Мы столкнулись с этой проблемой практически сразу после старта проекта. В силу того, что серверная часть реализована на Java, выбор с очевидностью пал на Maven. Оставалось найти плагин, который умеет работать с javascript.

Поиски были недолгими и привели на mojo.codehaus.org/javascript-maven-tools/. «То, что нужно»,- подумал я и начал прикручивать его к проекту.

Когда переводил на maven свои ejb3-проекты, порядком намучился с настройкой проекта, подключением «правильных» библиотек. Информации или не было, или она была устаревшей. В работе я использую JBoss 5.1.0.GA, поэтому все примеры будут на его основе.
Задача. Нужно создать maven2 проект для JBoss. Пусть, это будет Enterprise Application. Внутри — ejb3 модуль и web-приложение.

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

Прежде, чем обсуждать причины моего недовольства, нужно сказать пару слов о Мавене. Я не буду его подробно описывать, просто кратко изложу его основные особенности.

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

Для этих целей есть ряд библиотек из которых я использую Emma (офф. сайт).

Давным-давно я работал в одной большой компании, мы писали JEE приложения. Тогда еще была IntelliJ IDEA 4.0. Один из проектов состоял примерно из 30 модулей. Создание воркспейса с нуля занимало кучу времени, поэтому воркспейс хранился в svn. Кто-то сидел на IDEA 4.0, кто-то на IDEA 5.0, и когда кто-то комитил свои iml'ки и ipr'ки в svn, то другие жутко сердились из-за того, что слетали их личные настройки, поэтому у всех был свой личный воркспейс, а новые программисты мучались с уже нерабочим из svn.

Потом появился мавен и maven-idea-plugin, стало возможно создавать воркспейс из мавен проекта. Потом появился плагин «Maven Integration»: интеграция мавена и IDEA, стало возможно открывать сразу мавен проект.

В начале 2010 года у меня была пара проектов примерно с 20 модулями каждый, и я тратил немного времени на их настройку. Сейчас у меня 20 проектов, в каждом около 50 модулей, у каждого проекта есть несколько бранчей и тэгов. Было очень трудно создавать и переключаться между воркспейсами. Другим программистам тоже было трудно, они тоже тратили много времени на создание и настройку воркспейса. Было ощущение, что программисты совсем не тем занимались.

Меня в нашей группе попросили настроить среду и показать использование аспектов AspectJ и интеграция его со Spring.
Мне показалось, что хабросообществу это тоже может быть интересно.

Не буду рассказывать тут о том, что такое AspectJ, кто знает — тому будет полезно, замечу лишь, что аспекты — это возможность добавить на этапе компиляции или рантайма в классы некую функциональность, которой раньше там не было. Или изменить существующую.

Далее: конфигурация проекта и 3 примера аспектов.

Добрый день!

Про утилиту сборки для Java-проектов Maven и про возможность создания локального сервера для Maven-репозитория с помощью Sonatype Nexus на Хабре уже упоминали (тут и тут). Однако, никакого рецепта по этому поводу представлено не было. Это неудивительно при наличии достаточно полной грамотной документации. По долгу службы мне пришлось настраивать его на нашей фирме, и оказалось, что советы из официальной документации не совсем подходят. Возникшей проблемой и способом ее решения я и хочу поделиться с сообществом. Но обо всем по порядку.

Зачем это нужно?

Локальный сервер для Maven-репозитория (как, например, Sonatype Nexus) может быть использован для хранения локальных артефактов Maven, и действительно пригодится командам, которые разрабатывают модульные приложения, но не собираются публиковать модули в общий доступ.

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

Проблема

После сборки проекта с помощью Build сервера или на локальной машине требуется выложить полученное приложение на тестовый сервер.

Уже довольно долгое время использую мавен как инструмент для сборки проектов. Инструмент этот очень интересный и модный. Он особенно популярен среди java разработчиков хотя может быть полезен и в других областях. Так вот, сейчас я хотел бы рассказать о том, как можно с его помощью создать сайт. Не знаю для чего это может пригодиться вам, я пользуюсь этим для создания документации к проектам. В этой статье я попытаюсь создать html страницу содержащую текст из этой статьи и выглядещей как обычная статья на хабре.

Думаю, у многих возникала задача точно знать версию выпущенного jar'a или war'a. Причем хотелось бы иметь способ, позволяющий «простому пользователю» определить версию такого архива. Ниже приведен способ решения этой задачи.

 

UPD: Метод, аналогичный использованному здесь включен в поставку NuGet 1.6. Соответственно статья устарела.

Вот что мне всегда нравилось в джаве, так это Maven. Один файл со списком всего нужного, и никаких бинарников в репозитории. Когда появился NuPack, я решил — ура, вот оно, счастье пришло на нашу улицу. Но не тут то было. NuPack представлял удобный интерфейс для работы с пакетами… но без возможности нормально вкрутится в процесс сборки.

Поковырял я его тогда, посмотрел, но так реальной пользы и не увидел. Не больно большая помощь — качать ручными powershell-командами пакеты поименно. Ну да, удобнее, чем скачивать фиг знает откуда, да еще руками references добавлять, но ведь мне это далеко не каждый день нужно. В общем, игра не стоит свеч.

Но в один прекрасный день я понял, что с папкой Shared\Bin в моем сорц-контроле нужно что-то делать, ибо распухла она уже неимоверно. Решил глянуть я, не изменилось ли что-нибудь с NuPack-ом, который уже NuGet-ом стал именоваться? Нет, воз и дальше там.

Но у nuget.exe появилась интересная фича…