Jelenleg "kisebb" projektekhez Ant-ot, "nagyobbakhoz" Maven-t használunk. Itt a "kisebb" azt jelenti, hogy a projekt outcome-ja viszonylag egyszerű, -pl. egy darab jar fájl-, valamint a függőségi gráf nem túl szövevényes. A függőségeket paraszt módon betesszük verzió kontrollba, mert ezeken a projekteken olyan emberek is dolgoznak, akik nem feltétlenül vérbeli fejlesztők és könnyebb volt így csinálni, mint elmagyarázni a Maven vagy Ivy filozófiáját. Ezek a projektek egyébként főleg kísérletezések, kódkezdemények. Halkan megsúgom hogy olyan projekt is van, amit egy DOS vagy *n*x batch script rak össze.
A nagyobb projekt ott kezdődik, ahol a függőségek mérete megabájtos nagyságrendben mérhető és/vagy az outcome-ba felfedezhető valami hierarchikus szerkezet. Pl. a webalkalmazások tipikusan ilyenek. Itt a Maven jobban bevált.
Egyébként nem vagyok sem Ant sem Maven hívő. Olyan a kettőt összehasonlítani mint a vonalzót és a tolómérőt. Mind a kettő egy eszköz, ami nagyjából ugyanarra, de mégis kicsit másra jó. Van egyébként a Blog Subject Queue-mban egy Maven firkálmány abból az időből amikor ismerkedni kezdtem vele, de hosszú lett és csapongó, nem tetszik - nem publikáltam. Az egyik JUM-mal kapcsolatban viszont egyszer írtam róla. Az egyik probléma a Maven-nel, hogy elég magas a belépési küszöb. Nem lehet lépésről lépésre megismerni. Csak akkor kezdi az ember megérteni a lényegét, ha elolvasott párszor tíz oldalt. A hivatalos weboldalon található irományok engem elég nehezen vittek közel a tudáshoz, viszont a Better Builds With Maven még mindig egy viszonylag jól összeszedett letölthető dokumentum. Háromszáz oldalas.
A javalistán lévő márciusi OSS című thread-ban felfigyeltem néhány alternatív megoldásra. Egyik a Maven-hez készülő Polyglot, ami arról szól, hogy a projekt leírót nem csak XML-ben, hanem egyéb divatos nyelveken (Scala, Groovy, Clojure, Ruby) is össze lehet rakosgatni. Ha divatos nyelvek, akkor már lehet hogy érdemesebb lenne a Gradle-be, vagy az SBT-be belenézegetni, amik nem csak skin-ek a pom.xml-re. Ezekben közös, hogy kölcsönveszik a függőségkezelést és az archetype-ok koncepcióját a Maven-től (vagy az Ivy-től), de több szabadságot próbálnak adni a projekt leírása terén.
A Gradle Groovy-ra épít. Őszintén szólva engem egy pár perces olvasgatás után nem győz meg maradéktalanul. A stackoverflow-on találtam még egy ezzel kapcsolatos kérdést és a hozzá tartozó válaszokat. (Why use Gradle instead of Ant or Maven?) Egyébként nem is tiszta teljesen, hogy ez most deklaratív vagy procedurális eszköz. Ha jól értem ugyanúgy deklaratíve task-ok közötti függőségeket kell megadni mint Ant-ban, csak a task-okon belül van procedurális végrehajtás. Nekem éppen az nem kényelmes, hogy explicite meg kell adnom, hogy egy task mitől függ.
Az SBT (Simple Build Tool) pedig Scala-ra épít. Ugyanúgy nem adja meg azt a késztetést, hogy erőt fektessek egy Ant-projektból való átlépésre vagy egy új projekt SBT-ben való elindítására. Röviden, de viszonylag körmönfontan kell leírni a build-eléshez szükséges információkat, akkor már inkább maradok az XML-nél. De a Brizzled blogban találtam egy érvelést és tapasztalatmegosztást, ami talán később vagy másnak bejön.
Akinek van ezekről -vagy más egyéb build tool-okról- tapasztalata, az kalapálja be ide a kommentekhez bátran.
2010-04-01
Java build eszközök
Feliratkozás:
Megjegyzések küldése (Atom)
3 megjegyzés:
én hosszútávon a buildr-ben látok fantáziát (http://ond.vein.hu/~dyn/name-your-poison.jpg), de messze van még a mindennapokban élesben használhatótól
Ez igazán impresszív. Kösz!
Szerintem egyszerű projectekkel gyorsabb elindulni mavennel. Amikor már valami rohadtul túl van bonyolítva a project struktúrában és a módszerekben, akkor lesz gebasz a maven. Néhány féle kódgenerálás, kismilló plugin, vacakolás a lifecycle-okkal, még néhány különleges igény és már kész is a mavenes rémálom.
Megjegyzés küldése