Від Ant до Maven, а потім назад

Що краще: Ant чи Maven?

Почну статтю з констатації факту:  “Збірка проекту відіграє дуже важливу роль.” Чому? Погляньте на різноманіття систем, що призначені для того, щоб налаштувати, відкомпілювати, зархівувати – зібрати дистрибутив вашого проекту.

Розробники програмного забезпечення для  Unix платформи використовують GNU build system, що дозволяє перевірити конфігурацію операційної системи, на якій проходить збірка проекту, та обійти чисельні викрутаси, що зустрічаються в різних версіях Unix систем.

У світі Java дуже популярними є Ant та Maven.

Ant

Мураха – дуже корисне створіння, а організація мурашника значно складніша за бджолиний вулик чи осине гніздо.

Мураха, дуже працьовита істота.

Інструмент Ant повністю виправдовує свою назву. Він справжній трудяга. Володіючи практично безмежною гнучкістю, він виконує дуже багато рутинної роботи. З його допомогою при збірці проекту можуть бути реалізовані ваші найрізноманітніші примхи, адже він

• повністю зроблений на Java, а, значить, не залежить від платформи;
• використовує XML формат для файла-сценарія, що значно спрощує опис збірки  (наприклад, у порівнянні з файлами для make);
• легко розширюється;
• чудово інтегрований з багатьма IDE (IDEA, NetBeans, наш улюблений Eclipse).

З Ant ви отримуєте можливість компілювати, копіювати, видаляти файли, створювати zip/tar архіви чи директорії, пакувати щось в jar-файл, практично не задумуючись над тим, які процеси реально запускаються при цьому в операційній системі. Ось, погляньте тільки:

[sourcecode language='xml']

    





    
    
      
    

    
      
      
        
      

      
      
        
      
    

[/sourcecode]

Однак цей інструмент зовсім не передбачає механізму управління залежностями вашого проекту. Саме тому варто розглянути таку систему як Maven.

Maven

Ми вперше спробували Maven уже після кількох років роботи з Ant, і перше, що я можу сказати: вони абсолютно один на одного не схожі. Ідеї в Ant дуже подібні до тих, які притаманні make: розробник обдумує, які операції з вихідними файлами йому буде зручно автоматизувати, та описує їх – словом, робить, що хоче. Maven пропонує модель – POM (Project Object Model).

Структура проекту набуває досить чітко окреслених форм, а сам процес збірки проходить через набір визначених етапів – фаз. Об’єкт проекту містить інформацію про безліч різних деталей: опис, списки розробників та учасників, шлях до репозиторію системи контролю версій і ще багато-багато чого корисного для opensource-проектів. Фази збірки мають стандартний сценарій та можуть доповнюватися плагінами.

Maven накладає досить жорсткі (але й досить раціоанальні) обмеження стосовно структури та пропонує “серйозний” підхід до процесу збірки, а головним його коником є управління залежностями проекту. Поясню “на пальцях”. Знайдіть 3 різниці між двома структурами:

Структури проектів

Структури досить подібні, однак мають суттєві відмінності. Вже знайшли? Ось мої варіанти:

1. різні назви: там “ant-”, там “maven-”;
2. різні файли в корені проекту;
3. у проекті організованому через Maven немає директорії lib.

Використовуючи лише Ant для своїх проектів, ми повинні були самостійно збирати та складати в якомусь місці бібліотеки, які використовуються в наших розробках, відслідковувати, залежності цих бібіотек, залежності залежностей і т.д, і т.д. При цьому потрібно було не забувати слідкувати за їхніми версіями та сумісністю.

Maven суттєво зменшує наші турботи. В описанні об’єкта вашого проекту необхідно просто вказати, що саме вам буде необхідно (наприклад, Spring). Maven власноруч завантажить потрібні файли зі свого репозиторія, використає їх при компіляції, покладе в потрібне місце вашого дистрибутиву, а головне розв’яже проблеми з транзитивними залежностями (тобто завантажить ще кучу jar-файлів з циклу Apache “common-”). Необхідно лише описати все в pom.xml:

[sourcecode language='xhtml']

  4.0.0

  com.stanfy
  example
jar
  1.0-SNAPSHOT
  Example project
  http://stanfy.com.ua/blog

  
    
      junit
      junit
      4.0
      test
    
  


[/sourcecode]

Ще однією корисною фішкою Maven є архітипи – шаблони, за допомогою яких можна легко стартувати нові проекти, автоматично отримуючи початкові конфігураційні файли для зв’язки, наприклад, Struts, Spring, Hibernate.

Непогано звучить, еге ж? Але, на жаль, у багатьох випадках усі ці процеси на практиці не працювали так ідеально.

• По-перше, не завжди усі потрібні вам бібліотеки можна знайти у відкритих maven-репозиторіях через проблеми з ліцензіями.
• По-друге, відверто кажучи, усю цю систему досить важко підлаштовувати під свої специфічні потреби.
• По-третє, плагіни Eclipse для інтеграції з Maven працюють, м’яко кажучи, не надійно: ми ставили одразу два, щоб щось працювало.

Висновки

Отримавши досвід в попудові життєвого циклу проекту як за допомогою Ant, так і використовуючи Maven, ми вирішили побудувати власну систему для організації наших дітищ, яка б була наділена наступними якостями:

• бала б гнучкою, легко конфігурувалася, підлаштовувалася під проекти різних типів на різних мовах (Java, ActionScript, PHP);
• розв’язувала питання управління залежностями проекту;
• дозволяла б використовувати шаблони для створення нових проектів;
• надала б інструменти для легкої побудови процесу Continues Integration.

На даний момент ми відмовилися від  Maven в наших проектах та перевели їх на власну систему Star Pumas, яка побудована на основі Ant та Ivy – гнучкої системи управління залежностями.

Apache Ivy - основа Star Pumas

Найближчим часом Star Pumas має також інтегруватися з Grails. Про те, як побудована система Star Pumas та як вона розвивається, я розкажу у наступних статтях.