Общая информация
дисклэймер: широкая айтишная общественность собирается обсуждать всякое. разумеется собраться в то время, когда я буду в Украине у широкой общественности никак не вышло :) посему посильным вкладом в первую встречу будут заметки. я так решил, да.
систем автоматической сборки проектов на Java сущетсвует наверняка очень много. но самыми популярными и используемыми являются Ant и Maven2 (актуальным проектом является Maven2, Maven is dead и это было предрешено). собственно обе системы являются Java-приложениями и обе системы разработаны Apache Sotware Foundation. более того, Maven2 умеет вызывать изнутри себя Ant.
пара слов об Ant.
прекрасная и очень простая система автоматической сборки. для сборки нужен файл build.xml или любой другой xml. есть набор тасков, поставляемых с продуктом, есть бесчисленное множество тасков, поставляемых отдельно. можно писать свои таски, если очень нужно и не менее очень хочется.
основная идея автоматической сборки проекта -- это, разумеется, вызов javac. компилятора Java. однако вместе с компиляцей файлов приходится решать задачи создания и очистки октружения. создания и удаления каталогов, временных файлов, упаковки и распаковки проекта в различного рода архивы, приправленные различного рода дескрипторами.
основная идея Ant -- у нас есть набор property, у нас есть набор тасков, который работает с имеющимеся property. весь процесс сборки может быть описан последовательностью вызовов тасков и описания их зависимостей. все. больше ничего нет. остальное мы создаем сами -- от структуры каталогов до последовательностей вызовов, форматов и имен архивов, и прочия, и прочия, и прочия. полная свобода дествий при весьма интересных ограничениях. но основная речь не об Ant
И тут пришел Maven
самая главная проблема полной свободы дествий есть отсутсвие стандартов по-умолчанию. нужно в 151й раз создавать одни и теже каталоги, в одной и той же последовательности, в одной и той же структуре от проекта к проекту, от компьютера к компьютеру. при это нужно убедить коллег, старших товарищей, младших товарищей, конфигурэйшин менеджеров и менеджеров проекта, что эта структура проекта хороша. а кому-то нравится своя, а третьему вообще ничего не нравится и всякая структура есть зло и насилие над личностью.
Maven решает проблему стандартизации кталогов, для хранения исходников, ресурсов и файлов, сопутсвующих исходникам (jsp, images, css, deployment descriptors, etc) очень просто -- у него есть формат каталогов по-умолчанию. разумеется можно все переопределить, переназначить и тому подобное. просто делать это каждый раз утомительно и время на это тратить не целесообразно, есть более приоритетные задачи.
1. Maven предоставляет стандартизованную структуру каталогов для хранения исходников
вторая проблема Ant -- необходимость самостоятельно строить workflow сборки. включая очистку старого окружения, создание нового, изменение версий артефактов, именование артефактов и delivery-архивов.
Maven решает данную проблему опять-таки наличие стандартного механизма именования артефактов, размещения файлов релиза и тестирования, размещения ресурсов и промежуточных каталогов. так же у Maven есть предопределнный workflow, где все операции следуют в четкой, заранее определенной последовательности. на входе у нас исходники проекта, на выходе -- готовые jar/war/ear. если нам необходимо, то путем задания опреденных правил, мы можем сформировать delivery-архив и даже технический сайт проекта. просто используя соотвествующие части workflow, без дополнительного кодирования или установки правил.
2. Maven имеет стандартный build worlflow, стандартную политику именования артифактов, стандартные имена output каталогов для кода проекта, и кода тестов. Так Maven сам заботиться о том, чтобы необходимые ресурсы попали в необходимые артефакты.
третья проблема, которая является проблемой не только и не столько Ant, сколько программирования на Java вообще -- это проблема хранения библиотек. если с кодом все более-менее ясно и систем хранения и версионирования кода существует более чем достаточно, то с готовыми библиотеками все несколько сложнее. как правило эти готовые библиотеки кладутся в SVN рядом с исходниками. что сущетсвенно увеличивает время выгрузки исходников из системы контроля версий. более того, если имя библиотеки не содержит номера версии, то обновить таковую песня отдельная. хорошим вариантом является хранение библиотек отдельно от кода проекта. это решает проблему скорости обновления и checkout исходников проекта, но все-равно в SVN у нас остается несколько сот метров бинарного кода, который там просто лежит.
одна из главных особенностей Maven -- это возможность управления зависимостями. собственно Maven и создавался для того, чтобы решить проблему хранения готовых библиотек, их обновления и управления ими.
в случае Maven мы имеем некоторое количество репозиториев, которые хранят бинарные артефакты и метаданные к ним единым и стандартным способом. на уровне конфигурации сборки проекта тот или иной репозитарий может быть влючен в список источников, для поиска артефактов. артифактом является каждая бинарная библиотека, включающая:
- groupId - уникальный идентификатор группы. физически это каталог в кортне репозитория, относительно которого хранятся уже непосрественно версии библиотеки. Maven поддерживает именование в стиле Java package, это предоставляет возможность создавать не один каталог, а целое дерево с помощью данного аттрибута
- articatId - имя библиотеки. физически это и есть финальный файл библиотеки.
- version - весрия. физически это подкаталог в последнем каталоге дерева группы и постфик имени файла артифакта.
каждый модуль Maven и каждый модуль Вашего проекта под управлением Maven, так же есть артефактом. при первом обращении к тому или иному артефакту, Maven скачивает его из глобального репозитория в локальный, сформированный на Вашем локальном диске. в дальнейшем этот локальный репозиторий будет оновлятся новыми файлами и новыми версиями артефактов автоматически.
build workflow Maven позвольяет публиковать артефакты в любом, выбранном Вами репозитории, в связке с проектом Archiva это позволяет легко и просто создать корпоративное зеркало необходимых репозиториев и публиковать туда свои артефакты. что решает проблему обновления версий опять-таки стандартным способом.
3. Maven имеет мощный механизм управления внутренними и внешними зависимостями проекта. Maven стандартным образом решает проблему хранения бинарных файлов отдельно от исходного кода
Важно: проект Apache Ivy позволяет использовать репозитории артефактов Maven для управления зависимостями внутри проектов, собираемых с помощью Ant
С чего начинается Maven
для старта проекта под управлением Maven необходимо создать pom.xml (Project Object Model) файл в каталоге, который стане корневым для Вашего проекта. и разумеется скачать сам Maven.
