Muszę przyznać, że jeżeli chodzi o rekompilację ad-hoc przez długi czas “ograniczałem się” do Ant’a, który działał sobie razem z Eclipsem. Jednak z czasem, kiedy to pojawiały się większe projekty, które same z siebie wymuszały przestrzeganie faz produkcyjnych wpadło mi w ręce niesamowite narzędzie tj. Maven. Nie będę ukrywał, że zarówno Ant’a, jak i Maven’a poznałem “przez Jave”, i to właśnie swoje doświadczenia z Javy w tym względzie zacząłem przenosić na grunt Flex’a. Co to jest Maven? Mówiąc krótko jest to narzędzie, które ma za zadanie automatyzować zarówno proces kompilacji, buildowania i migracji wraz z procesem zarządzania projektem. Choć użycie sformułowania “zarządzania projektem” to być może za duże słowo, powiedzmy zarządzania fazami procesu wytwórczego alplikacji programowych. Jak to jest możliwe? Otóż każdy projekt składa się z modułów realizacyjnych, których podział wynika za zwyczaj pośrednio z tzw. WBS’a (Work Breakdown Structure), za który odpowiedzialny jest Project Manager. Modłuły funkcjonalne w całości, bądź po podziale na czynności są przekazywane do wdrożenia zespołom projektowym w danej metodologii, która zakłada dostarczanie pewnych artefaktów, zarówno papierowych, jak i programowych na końcu poszczególnych faz. W kontekście procesu produkcyjnego (tym bardziej jeżeli mamy do czynienia z tzw. procesem iteracyjnym)  przydałoby się narzędzie, które dbałoby o to, aby poszczególni członkowie zespołów mieli tożsame pliki konfiguracyjne środowisk wytwórczych,  pracowali wedle tych samych faz produkcyjnych oraz przestrzegali ich kolejności, w zorganizowany sposób dostarczali artefakty (zarówno papierowe tj. dokumentację, która za zwyczaj jest w formie elektronicznej, jak i programowe tj. zwersjonowane kody źródłowe), które składałyby się na kompletne modłuły, natomiast poszczególne moduły na gotowy produkt (w kontekście Flex’a lepiej chyba zamiast modułów, używać terminu – komponent, jakby nie było, przyjmijmy, że w kontekscie tego posta terminy te są dla mnie równoważne).

Na zdrowy rozsądek, narzędzie mające zautomatyzować i nadzorować powyższe kwestie powinno dysponować jakimś standardem opisu zależności pomiędzy poszczególnymi modułami, który krótko mówiąc opisywałby budowę aplikacji, a także szereg innych informacji dotyczących m.in. konfiguracji środowisk wytwórczych, generowania raportów, czy opisu zespołu projektowego wraz z referencją do zdefiniowanych wcześniej artefaktów, za które odpowiedzialni są poszczególni członkowie zespołu.

Narzędziem, które pozwala to zrobić jest Apache Maven, natomiast standardem dokumentu zawierającym definicje między innymi wymienionych wyżej aspektów jest POM – Project Object Model (który jasna sprawa bazuje na języku XML). Niestety ciężko by było w tym poście opisać poszczególne tagi niezbędne do tego, aby stworzyć POM – dlatego odsyłam do tego linku po specyfikację wraz z przykładami.

Jednak przed tym jak zaczniemy definiować POM’y musimy zainstalować plugin Maven’a do Flex SDK 2.0 (przyznam się, ze plugina z SDK 3 jeszcze nie używałem, nie wiem, czy da radę). Jakby nie było, plugin ten, nie jest może zbyt rozbudowany, niemniej jednak oferuje cztery bardzo przydatne dyrektywy (czynności) [ flex2:asdoc, flex2:compile-swc, flex2:copy-flex-applications, flex2:compile-swf], których nazwy mówią same za siebie i o których można sobie więcej poczytać tu. Przykłady użycia są tu. Jeżeli natomiast w swoich projektach używasz webserviceów WSDL’a polecam wsdl2as plugin, jest tam też plugin pod Maven’a – niezmiernie ułatwiająca życie sprawa.

Maven rządzi i jak dla mnie to teraźniejszość i przyszłość, z pewnością więc warto zapoznać się z nim w kontekście tworzenia rozbudowanych aplikacji Flex’owych.