Apache Ant 1.9.3

Vyšla nová verze Antu („javovský make“) Ant 1.9.3. Opravuje chybu #54128 – pomalost exec úloh (spouštění systémových příkazů) způsobenou neblokujícím I/O s periodou 100ms. Řeší také požadavek #21525 – podporu různých datových typů (čísla, boolean…) a XPath výrazů (výpočty, funkce) u parametrů XSL šablon (dřívější verze umožňovaly pouze předání textového řetězce). A další změny.

30.12.2013 09:07 | xkucf03 | Nová verze

Komentáře

Náš administrátor shledal tento komentář závadným.

Komentář cenzurován pro neslušné vyjadřování.

Zobrazit komentář

Náš administrátor shledal tento komentář závadným.

Vulgarity

Zobrazit komentář

[BigBoss]

Dělal jsem s Antem několik let a bylo to čisté peklo. Nedivil bych se, kdyby to byla pomsta KLDR západnímu světu. Ant a Hello World je možná OK. Ant a enterprise aplikace je čistá smrt.

[xkucf03]

Několik enterprise aplikací sestavovaných Antem jsem viděl. Není to ideální, ale že by to byla „čistá smrt“, to bych neřekl – dařilo se pravidelně dodávat nové verze a pokud byl nějaký problém, nebylo to způsobené Antem.

[Nikola Ciprich]

už v javě vůbec nedělám, takže jsem dost mimo, ale pro hodně velké aplikace je pak stejně lepší maven ne? jinak mi ant taky přišel celkem fajn, zvláště potom co jsem si za ty roky už užil s takovými autotools.. TO je peklo..

[Nikola Ciprich]

a ještě než se do mně někdo hned pustím, uznávám že jsou to dost hrušky a jabka, ale prostě fakt nemám rád autotools. je to hnůj.

[Hryzo]

Ono hlavne Ant a Maven su v podstate dost rozdielnej povahy.

- Ant je skriptovaci jazyk, bez riesenia zavislosti (hlavne medzi viacerymi modulmi - toto je v ante peklo a ani neviem ci sa to da vobec spravit !!!) s uplnou volnou strukturov - nic nediktuje, je to skriptovaci mechanizmus, ktory sa sklada z predom definovanych uloh

- Maven je naproti tomu zostavovaci nastroj, ktory sa opiera o pevne danu strukturu projektu (toto je hlavny rozdiel medzi antom). Ked ma nieco predpisanu strukturu, tak mozte lahsie reusovat jednotlive ulohy. Dalej riesi zavislosti medzi modulmi, podporuje multimodul projekty a pod. A to najdolezitejsie - ma build lifecycle o ktory sa opieraju jednolitlive pluginy (nieco ako v ante tasky) - nemusim riesit, kedy sa ma spustit kompilacia, kedy sa ma spravit JAR, kedy sa maju kopirovat resources - len nakomfingurujem a Maven vie, kedy ma co spustit.

Antom aj Mavenom sa da spravit to iste, ale Mavenom daleko daleko pohldnejsie. Osobne mi Gradle pride ako krok spat k Antu, ale to je len moj nazor.

[mich]

Už tomu je více než rok, co jsme se v mé bývalé práci naštvali, že ant skripty co sestavují naši aplikaci jsou nepřehledná, polofunkční šílenost. Nicméně řešení bylo jednoduché - zůstali jsme u antu, ale opakující se části jsme přepsali do antovských maker a použili jsme apache ivy na řešení závislostí. Najednou sestavování začalo fungovat dobře a dalo se v tom jednoduše vyznat. Často to prostě není problém antu, ale problém toho prasete, co ty skripty psalo.

[BigBoss]

Představte si situaci, kdy se o Enterprise aplikaci tahá více firem a vzájemně si ji po "manažerských rozhodnutích" předávají. Firma, které vývoj berou chce, aby byl nástupce viděn, jako neschopný a naopak ta firma co to dostane nemá ochotu do toho příliš investovat. Dokumentaci píšou výhradně programátoři, kteří jsou ve výpovědní době:)

[xkucf03]

Takže se hezky dostáváme k tomu, že problém je někde jinde než v Antu

[Hryzo]

A preco ste rovno nepresli na Maven? Nebolo by to daleko jednoduchsie? Sam som migroval niekolko ant skriptov na maven a este sa mi nestalo, ze by nieco neslo. V jednom pripade som to riesil cez maven-ant-plugin, pretoze v ante maly vyskakovaci PROMPT.

[mx]

Prováděl jsem mavenizaci několika větších (spíš velkých) ANT projektů.

Sám jsem maven propagoval, kde jsem mohl, ale už jsem si tolikrát nabyl hubu kvůli tomu, jak je Maven neohrabaný (a jeho vývoj, potažmo bugfixy brutálně pomalý).

(pro zájemce můžu vypsat, co je na Mavenu totální průs... :D)

Takže řešení: - buď zůstat u antu a delegovat dependency management na Ivy (jak už tu někdo napsal), - nebo přejít např. na Gradle (pokrývá nejenom javu, btw.) (který za sebou má mimochodem Ivy taky)

[Marián Petráš]

Vzbudil jste u mne zájem. Tak tedy: Co je na Mavenu totální průs...?

(Neptám se proto, abych s Vámi mohl polemizoval, ale abych se poučil od někoho kdo si už nabil hubu - abych si ji třeba nemusel nabít sám).

[pam]

Na mavenu je hrozne, ze musi byt po jeho. Mate definovany postupy, pokud se vam nelibi, smula. Napr. jak v prostredi eclipse vyvijet vice maven projektu na jednom tomcat serveru? Jak provest remote deploy na websphere? Jak zmenit pri deploy aplikace web.xml? A takovych veci je fura. Maven je vyborny pokud vam vyhovuje tak, jak je, jakakoli uprave je nesmirne slozita. Na druhou stranu, pokud prijde vyvojar a umi maven, muze druhy den po nastupu do zamestnani pracovat. Ja propaguji na slozite projety (a slozite z hlediska architektury - ruzna prostredi, ruzne casti aplikace, bezi na ruznych serverech) preddefinovane ant tasky s apache ivy.

[xkucf03]

Na mavenu je hrozne, ze musi byt po jeho. Mate definovany postupy, pokud se vam nelibi, smula. Napr. jak v prostredi eclipse vyvijet vice maven projektu na jednom tomcat serveru? Jak provest remote deploy na websphere? Jak zmenit pri deploy aplikace web.xml? A takovych veci je fura.

V tomhle se mi líbí projekty v Netbeans a jejich antovské skripty – má to určité předdefinované chování (celkem dobré) a k němu si snadno můžeš dopsat vlastní věci – přidat úlohy (případně překopat ty antovské skripty nějak víc):

      -pre-init:                 called before initialization of project properties
      -post-init:                called after initialization of project properties
      -pre-compile:              called before javac compilation
      -post-compile:             called after javac compilation
      -pre-compile-single:       called before javac compilation of single file
      -post-compile-single:      called after javac compilation of single file
      -pre-compile-test:         called before javac compilation of JUnit tests
      -post-compile-test:        called after javac compilation of JUnit tests
      -pre-compile-test-single:  called before javac compilation of single JUnit test
      -post-compile-test-single: called after javac compilation of single JUunit test
      -pre-jar:                  called before JAR building
      -post-jar:                 called after JAR building
      -post-clean:               called after cleaning build products

Takže jsem si třeba jednoduše upravil deploy na aplikační server, aby neprobíhal přes HTTP API, ale aby se .ear nahrál pomocí scp a nasadil příkazem volaným přes SSH.