Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: tomas88 29. 11. 2020, 09:02:07
-
Pripad - potkalo se vice lidi (kteri se temer neznaji) na novem projektu. Ti zkusenejsi a s vetsi vahou hlasu jsou pro Maven. Gradle vesmes neznaji. Prijde jim nebezpecna flexibilita kterou Gradle nabizi. Me to naopak prijde jako ohromna vyhoda a velmi nerad bych se po dlouhe dobe vracel zpet k Mavenu. Uz jsem vystridal nekolik build nastroju a vzdy se mi pracovalo lepe s takovym, co pouzival primo programovaci jazyk. Nemate nejake tipy jak takove lidi presvedcit? Vidi to nekdo jinak?
-
Já v Javě a v její ekosystému nedělám, jen okrajově, ze zájmu (Kotlin, Scala), ale vidím to stejně.
Mohl by jste jim připomenout jak <ironie>krásné</ironie> je XML. Věřím, že když si zkusí Gradle (doporučuji Kotlin Script namísto Groovy), že se jim ke XML vracet chtít nebude.
-
Pokud neplánuješ "programovat" build 4 hodiny denně, tak je to úplně jedno. Hádat se kvůli buildu, když ještě nikdo nenapsal ani řádek, je trochu předčasné.
-
Mohl by jste jim připomenout jak <ironie>krásné</ironie> je XML.
Proč ta ironie? XML _je_ krásné.
-
Nemate nejake tipy jak takove lidi presvedcit?
Jednoduše. Najdi jednu nebo několik věcí v projektu, které se s Gradle dají vyřešit mnohem jenodušeji / lépe, než s Mavenem.
-
Kritérium je, myslím, poměrně zřejmé: budete skutečně vyvíjet nějaký buildscript? Budete skutečně potřebovat něco, na co není standardní (a dobře fungující) maven plugin?
Pokud ano, tak je volba jasná - gradle. Psát si vlastní maven plugin je většinou overkill a pokusy o psaní scriptů v pom.xml jsou jasným znakem začátečníků a šílenců.
Pokud ne, tak přichází do hry další aspekty - co kdo zná (a na co je zvyklý), jaké další nástroje se používají - především IDE a CI. Pokud někteří z těch lidí používají "alternativní" IDE (tj. ne Idea) a pokud buildserver nemá dobrý plugin pro gradle (ale má pro maven), tak budete X let řešit brblání, žbrblání a nadávání na "frikulíny" a jejich "kurvítka" (další termíny naleznete na dfens-cz.com).
Jo a rozhodně varuji před argumentem "xml je fuj", to je nejlepší způsob jak se zdiskreditovat.
-
...
Me to naopak prijde jako ohromna vyhoda a velmi nerad bych se po dlouhe dobe vracel zpet k Mavenu.
...
Tak bych zacal tady... Kdyz se nechces vracet tak videl/zazil nejaky problem s mavenem.
Zkus udelat minimalni priklad, ktery ho ukaze.
A pak ukazat jak to krasne vyresi gradle.
Pak se zamysli, jestli je to relevantni pro vas novy projekt a jestli neni sance to vyresit jeste elegantneji.
A pak to ukaz kolegum( a treba i nam) a uvidis co z toho bude...
A hlavne se tim moc netrap... ono je to totiz skoro jedno vzhledem k tomu jak casto je do toho potreba sahat...
-
Pokud má build proces umět jen běžné standardní věci, je to celkem jedno. Kouknul bych u obou na podpora v IDE a šel cestou nejmenšího odporu. Osobně používám Maven - mám jeden pom.xml který dělá co potřebuju a ten používám všude. Jak to přesně funguje, to popravdě řečeno netuším.
Konfigurovat build proces bych stejně nechal dělat nějakého zkušenějšího kolegu, tak ať si vybere spíš on.
-
Pokud neplánuješ "programovat" build 4 hodiny denně, tak je to úplně jedno. Hádat se kvůli buildu, když ještě nikdo nenapsal ani řádek, je trochu předčasné.
Zmenit jiste veci v pozdejsich fazich projektu muze byt pomerne drahe. A build tool je jednou z nich. Delame zakazkovy vyvoj a do takove zmeny nikdo neinvestuje.
-
Kritérium je, myslím, poměrně zřejmé: budete skutečně vyvíjet nějaký buildscript? Budete skutečně potřebovat něco, na co není standardní (a dobře fungující) maven plugin?
Pokud ano, tak je volba jasná - gradle. Psát si vlastní maven plugin je většinou overkill a pokusy o psaní scriptů v pom.xml jsou jasným znakem začátečníků a šílenců.
Pokud ne, tak přichází do hry další aspekty - co kdo zná (a na co je zvyklý), jaké další nástroje se používají - především IDE a CI. Pokud někteří z těch lidí používají "alternativní" IDE (tj. ne Idea) a pokud buildserver nemá dobrý plugin pro gradle (ale má pro maven), tak budete X let řešit brblání, žbrblání a nadávání na "frikulíny" a jejich "kurvítka" (další termíny naleznete na dfens-cz.com).
Jo a rozhodně varuji před argumentem "xml je fuj", to je nejlepší způsob jak se zdiskreditovat.
To je prave ono. Ono casem se narazi na problem, ze na neco standardni maven pluginy nestacej a zacnou v projektu pribyvat shell skripty, a nakonec se zacne skriptovat i v predpisu pro build server (mam na mysli soubor jako Jenkinsfile a ruzne ekvivalenty). Takze se neda jednoduse migrovat projekt na jiny build server.
-
...
Me to naopak prijde jako ohromna vyhoda a velmi nerad bych se po dlouhe dobe vracel zpet k Mavenu.
...
Tak bych zacal tady... Kdyz se nechces vracet tak videl/zazil nejaky problem s mavenem.
Zkus udelat minimalni priklad, ktery ho ukaze.
A pak ukazat jak to krasne vyresi gradle.
Pak se zamysli, jestli je to relevantni pro vas novy projekt a jestli neni sance to vyresit jeste elegantneji.
A pak to ukaz kolegum( a treba i nam) a uvidis co z toho bude...
A hlavne se tim moc netrap... ono je to totiz skoro jedno vzhledem k tomu jak casto je do toho potreba sahat...
Popravde nejsem zadny Maven expert. Na pozici java backend developer jsem relativne kratce a projekty jsem dosud spise prebiral nez neco tvoril. Ale trapi me to hodne. Protoze to co prebiram je plne Maven + skripty + dalsi balast. A travim upravou toho, aby to slo jednoduse zbuildit/rozebehnout/podporovat/deployovat dosti casu.
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
-
Mam rozsiahle skusenosti s vyvojom v Jave, Maven pouzivam skoro celu dobu a s Gradlom mam tiez skusenosti.
Na zaciatok by som odporucal pocuvat rady skusenejsich kolegov - ked su za jedno z rieseni, vychadza to z nejakych skusenosti a ked ich nevies presvedcit, teda nemas argumenty, tak by som sa riadil ich radami, kym tie skusenosti nenaberies.
K vyhodam a nevyhodam jednotlivych toolov:
Maven
-------
+ je to standardizovany nastroj, ktory ma velku podporu IDE a ked sa drzis standardu, tak vsetko funguje a nemas problem (bohuzial si casto ludia mylne myslia, ze ich problem je specialny a do standardu sa nevojdu a potom si len hadzu klacky pod nohy a maju problem - osobne som na jednom projekte stretol)
+ standard znamena, ze novi ludia hned vedia, ako projekt zbuildit, pustit testy etc. - nemusia sa ucit ako zbuildit zrovna ten tvoj projekt a pri prechode na iny projekt tieto vedemosti dumpnut do /dev/null
- je to build tool - ak potrebujes cosi navyse, tak to musis vyriesit inac (napr shell skript alebo spominany gradle - da sa kombinovat, nie je to bud/alebo)
- ak mas naozaj specificky problem (nepravdepodobne ale stat sa moze), tak je to neflexibilne riesnie
Gradle
--------
+ kedysi bol marketovany primarne ako automation tool (ktory zvladal buildit) - takze za mna flexibilny skriptovaci nastroj s JVM jazykom a kvantom kniznic, ktore sa daju pouzit
- ako v dobach antu - pises si cely build skript od zaciatku a co projekt, to inac vyzerajuci skript a ludia sa musia ucit pustat nieco uplne ine
- videl som pouzitie v rukach nedostatocne skusenych ludi a po par rokoch sa to moze cele zahodit a napisat znovu, lebo nikto netusi, co ta vec vlastne robi (ked sa niekto snazi, tak aj maven dokaze byt neprehladny, ale gradle moze byt peklo)
Takze u normalnych projektov u mna urcite Maven, pripadne doplnit niecim dalsim pre extra veci.
-
...
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
Kolik profilu typicky v projektu mate? A na co je pouzivate? Treba je "zneuzivate" na neco co by slo resit jinak?
-
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
Maven snad neumí podmíněné zpracování? Nacpal bych to do jednoho profilu a parametricky se přepínal mezi větvemi.
-
Mam rozsiahle skusenosti s vyvojom v Jave, Maven pouzivam skoro celu dobu a s Gradlom mam tiez skusenosti.
Na zaciatok by som odporucal pocuvat rady skusenejsich kolegov - ked su za jedno z rieseni, vychadza to z nejakych skusenosti a ked ich nevies presvedcit, teda nemas argumenty, tak by som sa riadil ich radami, kym tie skusenosti nenaberies.
K vyhodam a nevyhodam jednotlivych toolov:
Maven
-------
+ je to standardizovany nastroj, ktory ma velku podporu IDE a ked sa drzis standardu, tak vsetko funguje a nemas problem (bohuzial si casto ludia mylne myslia, ze ich problem je specialny a do standardu sa nevojdu a potom si len hadzu klacky pod nohy a maju problem - osobne som na jednom projekte stretol)
+ standard znamena, ze novi ludia hned vedia, ako projekt zbuildit, pustit testy etc. - nemusia sa ucit ako zbuildit zrovna ten tvoj projekt a pri prechode na iny projekt tieto vedemosti dumpnut do /dev/null
- je to build tool - ak potrebujes cosi navyse, tak to musis vyriesit inac (napr shell skript alebo spominany gradle - da sa kombinovat, nie je to bud/alebo)
- ak mas naozaj specificky problem (nepravdepodobne ale stat sa moze), tak je to neflexibilne riesnie
Gradle
--------
+ kedysi bol marketovany primarne ako automation tool (ktory zvladal buildit) - takze za mna flexibilny skriptovaci nastroj s JVM jazykom a kvantom kniznic, ktore sa daju pouzit
- ako v dobach antu - pises si cely build skript od zaciatku a co projekt, to inac vyzerajuci skript a ludia sa musia ucit pustat nieco uplne ine
- videl som pouzitie v rukach nedostatocne skusenych ludi a po par rokoch sa to moze cele zahodit a napisat znovu, lebo nikto netusi, co ta vec vlastne robi (ked sa niekto snazi, tak aj maven dokaze byt neprehladny, ale gradle moze byt peklo)
Takze u normalnych projektov u mna urcite Maven, pripadne doplnit niecim dalsim pre extra veci.
Proc beres podporu v IDE jako vyhodu Mavenu? Podle me jsou oba nastroje tak rozsirene, ze to vyjde uplne na stejno - podporad je skvela.
Proc se bere ze Gradle je nestandardni? Ze novy lidi maji problem udelat build, spustit testy? Vzdyt filozoficky je to uplne stejne. V jadru je standardizovany lifecycle. Kazdy kdo zna Maven/Gradle bude umet spustit testy v Maven/Gradle.
Ant prakticky vubec neznam. Nikdy jsem v tom nedelal. Ale ze by bylo potreba si psat cely build skript v Gradle od zacatku? To snad ne. V mavenu nastavim maven-compiler. V gradle nastavim java plugin. A je to. Me to prijde v obou pripadech to same. V cem je rozdil ze si v Gradle musim psat cely build skript od zacatku?
-
...
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
Kolik profilu typicky v projektu mate? A na co je pouzivate? Treba je "zneuzivate" na neco co by slo resit jinak?
Konkretne jsem resil ovladani db skrze maven-liquibase-plugin. Tudis jsem chtel mit profily pro build javy a profily pro db. A mit moznost si je kombinovat dle libosti. To jest spustit mvn jako "k jave se chovej podle profilu a/b/c a k db podle profilu x/y/z". Proste mit db ovladanou pomoci jinych profilu nez samotnou java aplikaci. Muze to byt zneuzivani maven profilu... ale potom nechapu na co ten maven-liquibase-plugin je dobry.
-
Prosim, skuste dat vediet, co sa snaite profilmy riesit. Zvacsa nie je nic rozumne na projekte, co by sa mohlo profilmi riesit. Ak ich chcete mat viac paralelne zapnutych naraz, tak tam nie je ziaden problem. Staci vymenovat za prepinacom profilov a oddelit ciarkou. Daku sa aj aktivovat aj takto pekne napriklad https://stackoverflow.com/a/943474/3679328
PS: Za mna je maven build tool. Ma to vediet dodat build. Teda jar/war/docker img/zip/exe/... Nic ine. Vysledna vec ma byt vpodstate vzdy rovnaka (pre kazde pouitie/prostredie). Inak pojdete proti devops paradigme (kazdy build moze skoncit v produkcii). Akekolvek (casto risene profilom veci) parametrizacie projektu (adresy databazy, loglevel a podobne) maju byt riesene az v runtime (respektive pri instalacii napriklad). Gradle je fajn, ale uciaca sa krivka noveho cloveka je o rad horsia. Spravit ale korektne a poriadne maven build moze vyzadovat tiez dost znalosti...
-
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
Maven snad neumí podmíněné zpracování? Nacpal bych to do jednoho profilu a parametricky se přepínal mezi větvemi.
Nerikam ze neumi. Jen me ty profily u mavenu prijdou takove dosti divne / omezene. Ale muze to byt i moje neznalost problematiky. Popravde nechapu co myslis tema větvemi - jako v Gitu?
-
Proc beres podporu v IDE jako vyhodu Mavenu? Podle me jsou oba nastroje tak rozsirene, ze to vyjde uplne na stejno - podporad je skvela.
Proc se bere ze Gradle je nestandardni? Ze novy lidi maji problem udelat build, spustit testy? Vzdyt filozoficky je to uplne stejne. V jadru je standardizovany lifecycle. Kazdy kdo zna Maven/Gradle bude umet spustit testy v Maven/Gradle.
Ant prakticky vubec neznam. Nikdy jsem v tom nedelal. Ale ze by bylo potreba si psat cely build skript v Gradle od zacatku? To snad ne. V mavenu nastavim maven-compiler. V gradle nastavim java plugin. A je to. Me to prijde v obou pripadech to same. V cem je rozdil ze si v Gradle musim psat cely build skript od zacatku?
Zalezi jak moc custom chces byt. Ak sa chces drzat standardov, tak IMO staci Maven. Ak chces viac customizovat (zazil som aj to, ze bol problem standardny directory layout), tak tooly problem mat mozu, lebo s niektorymi vecami nerataju...aj ked to uz bolo par rokov dozadu.
Ad spustanie buildu a testov - kto pozna Maven, tak ich bude vediet spustit. U Gradlu zalezi na tom, jak moc velku fantaziu autor ma a je mozne, ze sa budes musiet naucit nazov targetu pre dany projekt, co je zbytocne.
Ad pisanie build skriptu - ak nechces nic custom, nepotrebujes Gradle, ak chces custom, tak si pises build skript.
-
Napada me treba problem s maven profily jakozto jednorozmerneho pole. Nelze vytvorit dva (nebo i vice) nezavisle sety profilu a jednoduse je kombinovat. Jedine mit vypsanou kombinaci kazdy s kazdym coz je vcelku des.
Maven snad neumí podmíněné zpracování? Nacpal bych to do jednoho profilu a parametricky se přepínal mezi větvemi.
Nerikam ze neumi. Jen me ty profily u mavenu prijdou takove dosti divne / omezene. Ale muze to byt i moje neznalost problematiky. Popravde nechapu co myslis tema větvemi - jako v Gitu?
V GNU make si nadefinuji různé vstupní body, každý definuje, jak se má výsledek sestavit. Maven to má také. Doporučuji, aby se každý výsledek odlišného buildu jmenoval jinak, ať se ti to nepoplete.
Větvemi jsem mínil tvé sety profilů, které nacpeš všechny do jediného profilu. Tím se zbavíš duplicit.
-
Zalezi jak moc custom chces byt. Ak sa chces drzat standardov, tak IMO staci Maven. Ak chces viac customizovat (zazil som aj to, ze bol problem standardny directory layout), tak tooly problem mat mozu, lebo s niektorymi vecami nerataju...aj ked to uz bolo par rokov dozadu.
Ad spustanie buildu a testov - kto pozna Maven, tak ich bude vediet spustit. U Gradlu zalezi na tom, jak moc velku fantaziu autor ma a je mozne, ze sa budes musiet naucit nazov targetu pre dany projekt, co je zbytocne.
Ad pisanie build skriptu - ak nechces nic custom, nepotrebujes Gradle, ak chces custom, tak si pises build skript.
Me prave prijde skvele, ze muzu vyuzit standard, ktery mi ve vetsine pripadu staci a je tou nejlepsi volbou. Ale kdyz potrebuju nahodou neco custom, tak nemusim ohybat maven, nebo vymyslet nejake kulisarny, abych toho docilil.
No a s tou fantazii autora. Tak budto to ma nejaky smysl udela custom a nebo nema. Proc se jako vyhoda Mavenu bere, ze to potlacuje fantazii autora a vynucuje to podrizeni buildu moznostem Mavenu, vlastne moznostem dostupnym maven pluginu? Vzdyt toho sameho cloveka pak nechame programovat a tam uz mu jako verime, ze to udela dobre? Vzdyt samotnou tvorbou programu muze napachat daleko vetsi skody. Nebo mu neverime, ale proste nikoho jineho nemame, tak nam nic jineho nezbyva nez mu verit?
-
V GNU make si nadefinuji různé vstupní body, každý definuje, jak se má výsledek sestavit. Maven to má také. Doporučuji, aby se každý výsledek odlišného buildu jmenoval jinak, ať se ti to nepoplete.
Větvemi jsem mínil tvé sety profilů, které nacpeš všechny do jediného profilu. Tím se zbavíš duplicit.
To je zajimavy pristup. S GNU make jsem se pri programovani javy jeste nesetkal (pokud se neresilo kooperace s C++). No nevim jestli by to obstalo jako standardni pristup :D
-
Popište co má ten váš projekt řešit a co chcete řešít v rámci buildu - zkušenější vám pak řeknou, jak to řešit v Maven a Gradle a vy se budete moci rozhodnout co a jak. Pokud se ale ptáte jen takto obecně, tak to raději nechte na seniorních lidech z týmu. Za mě se má build systém postarat hlavně o závislosti a výslednou spustitelnou podobu programu a to umí Maven dobře a s přehledným pom.xml.
Ale pokud chcete řešit i nasazení, integrační testy, migrační skripty a podobně, tak máte mnohem větší téma než zda volit Maven či Gradle.
-
V GNU make si nadefinuji různé vstupní body, každý definuje, jak se má výsledek sestavit. Maven to má také. Doporučuji, aby se každý výsledek odlišného buildu jmenoval jinak, ať se ti to nepoplete.
Větvemi jsem mínil tvé sety profilů, které nacpeš všechny do jediného profilu. Tím se zbavíš duplicit.
To je zajimavy pristup. S GNU make jsem se pri programovani javy jeste nesetkal (pokud se neresilo kooperace s C++). No nevim jestli by to obstalo jako standardni pristup :D
GNU make se na Javu moc nehodí, tam je doma Ant nebo Maven. Pro jiné jazyky, např. C, C++, PHP a mnoho dalších je GNU make vhodnější. Má však jednu významnou nevýhodu - závislost na platformě. To ho poněkud diskvalifikuje ve smíšených týmech. Proto ho používám pro privátní buildery, které mi tak se zbytkem týmu nekolidují.
-
Popište co má ten váš projekt řešit a co chcete řešít v rámci buildu - zkušenější vám pak řeknou, jak to řešit v Maven a Gradle a vy se budete moci rozhodnout co a jak. Pokud se ale ptáte jen takto obecně, tak to raději nechte na seniorních lidech z týmu. Za mě se má build systém postarat hlavně o závislosti a výslednou spustitelnou podobu programu a to umí Maven dobře a s přehledným pom.xml.
Ale pokud chcete řešit i nasazení, integrační testy, migrační skripty a podobně, tak máte mnohem větší téma než zda volit Maven či Gradle.
To je prave problem to nechat na seniornich lidech. Trochu ty seniorni java backend programatory podeziram, ze znaji jen svatou trojici - java8 / maven / spring a tim koncej. Vyhovuje jim to. Coz by bylo dobre... Jen se bojim, ze jim to vyhovuje, protoze v tom delaji dlouho... Ja jsem v teto oblasti (java backend) pomerne novy, ale vyrobe SW se uz venuju docela dlouho a odzkousel jsem si mnoho jinych veci.
Jinak jo. Resim to kompletne. Vlastne neresim vcelku nic konkretniho. Spise se snazim pochopit proc ti seniorni java backend vyvojari tak trvaji na urcitych vecech, kdyz se ty veci daji delat jednoduseji, elegantneji.
-
Me prave prijde skvele, ze muzu vyuzit standard, ktery mi ve vetsine pripadu staci a je tou nejlepsi volbou. Ale kdyz potrebuju nahodou neco custom, tak nemusim ohybat maven, nebo vymyslet nejake kulisarny, abych toho docilil.
No a s tou fantazii autora. Tak budto to ma nejaky smysl udela custom a nebo nema. Proc se jako vyhoda Mavenu bere, ze to potlacuje fantazii autora a vynucuje to podrizeni buildu moznostem Mavenu, vlastne moznostem dostupnym maven pluginu? Vzdyt toho sameho cloveka pak nechame programovat a tam uz mu jako verime, ze to udela dobre? Vzdyt samotnou tvorbou programu muze napachat daleko vetsi skody. Nebo mu neverime, ale proste nikoho jineho nemame, tak nam nic jineho nezbyva nez mu verit?
Tu to uz naraza na tie skusenosti. Pracoval som v (malych) jednotkach (kusov) timov, kde boli sami kompetni ludia a nebol problem. Vetsinova skusenost je ale, ze timy su namixovane rozne seniornymi a kompetentnymi ludmi.
Potom sa stava, ze ked ten clovek nepozna dobre riesenie v podobe nejakej konfiguracie alebo pluginu, tak si ho proste dobastli v nejakom build skripte. Okrem toho vela ludi ma z nejakeho dovodu ovela nizsie standardy na kvalitu kodu u build skriptov nez u aplikacneho kodu, takze sa to moze zvrtnut (a aj zvrtne).
Mozes argumentovat s code review a ano, dost casto sa tam veci odfiltruju, ale niekedy na to nie je cas, pripadne mas seniorov na dovolenke a tieto veci sa tam zanesu.
Takze v pripade menej kompetentneho timu je obmedzenie moznosti dobra vec. A ako som pisal predtym, ak chces nieco viac, nemusis to nutne prepisovat do ineho toolu, ani si pisat vlastny plugin, tooly sa proste daju kombinovat.
-
Spise se snazim pochopit proc ti seniorni java backend vyvojari tak trvaji na urcitych vecech, kdyz se ty veci daji delat jednoduseji, elegantneji.
Hele, napsal jsi sem už deset příspěvků. A zatím ani jeden konkrétní příklad těch věcí, co by (ve vašem projektu) Gradle dělalo "jednodušeji, elegantněji".
-
Používám hlavně gradle, protože vytváříme víc než jen jar soubory. Vytváříme instalační archiv izpack a je tam spousta věcí, které potřebujeme automatizovat. Pokud má celý projekt jen jar výstupy, které se nahrají do nějaké repository, tak je maven asi ok.
U nás byl třeba problém se závislostma. Některé závislosti třetích stran musí do tomcat/lib, některé tam nejsou potřeba, tak jsou ve war/lib.
Pokud je nově závislost potřeba v tomcat/lib, ale je už použita ve war, tak se musí při vytváření instalačního archivu zařadit mezi jar soubory, které se kopírují do tomcat/lib. Toto jsem byl schopen v gradle automatizovat. Dřív (maven 1 ) se to udžovalo ručně ...
Pokud budou trvat na maven, tak jim to "svěřte", ať dělají údržbu buildovacího systému oni.
Na produktu, kde se od maven 1 nehneme jsem začal používat gradle aspoň na vývojářské tasky. project.xml (nový maven to má v pom.xml) načítám xml a parsuju si závislosti pro gradle ručně. Tím zajistím, že jsou všude stejné závislosti a můžu využívat výhod gradle aspoň při vývoji.
Gradle je super, když někdo dojde, že potřebuje něco trochu jinak. Je to otázka na pár minut. U Mavenu 2 jsem narážel na problémy, že bylo potřeba měnit naše postupy a přizpůsobovat se Mavenu, to bylo těžké obzvlášť, když na nás navazoval někdo další a nechtěl dělat změny ...
Gradle má konvence, jako Maven, ale je možné je porušovat.
Umí už Maven paralelní build tak jako Gradle? Toto není k flameware, u Mavenu2 a novější jsem jen uživatel, který sem tam něco builduje. Může to být ten argument, který hledáte, že parallel build v gradle dokáže dost šetřit čas. Build process se nám podařilo díky paralelnímu buildování výrazně zredukovat.
Další fičura v Gradle je inkrementální build, kde se builduje jen to, co se změnilo. Toto dokáže redukovat běh buildu na sekundy i když plný build běží třeba i několik minut.
Další věc, kterou využíváme, je možnost kombinovat jednotlivé tasky, jak jsou právě potřeba. Nevím, jestli mvn profily dokážou být až tak flexibilní.
Asi bych nechal lidi, kteří budou ten build udržovat, ať si vyberou. Přepsat se to dá vždycky a nemyslím si, že to je tak časově náročné. Náročné je to jen tehdy, pokud nový build system neznáte.
-
To je prave problem to nechat na seniornich lidech. Trochu ty seniorni java backend programatory podeziram, ze znaji jen svatou trojici - java8 / maven / spring a tim koncej. Vyhovuje jim to. Coz by bylo dobre... Jen se bojim, ze jim to vyhovuje, protoze v tom delaji dlouho... Ja jsem v teto oblasti (java backend) pomerne novy, ale vyrobe SW se uz venuju docela dlouho a odzkousel jsem si mnoho jinych veci.
Nevěřím, že by neznali Gradle - Gradle není žádná hipsteřina. Pokud by znali jen java 8, Maven a Spring tak je to pro projekt IMHO problém. Jako ne že by nemohli být užiteční, ale přibral bych do týmu ještě někoho dalšího, kdo má up-to-date znalosti a kdo pomůže, aby byl kód přiměřeně moderní.
Proč to ale neřešíte přímo s nima?
-
Mihnul sem se kolem projektu kde meli na confluence na titulni strance pro vyvojare napsano: Pokud lehne build tak pouzijte tyhle prikazy na pozabijeni vsech gradle deamonu a podprocesu ktere to vytvorilo a zkuste to znova.
A jeden z vyvojaru tam mel napsanej script v antu kterej presne tohle delal.... :-)
A jeste si pamatuju projekt kde se poustel script kterej poustel maven... ten vnitrne poustel pomoci antrun pluginu ant.... ten sam poustel nekolik bash a perl scriptu... jeden z tech perl scriptu myslim generoval a poustel nejaky make fily... a jeden z tech scriptu dokonce znova poustel maven...
A ja mel na starosti to znova uchodit po migraci repozitaru a build serveru.... Krasne straveny tyden :-D
Pointa.... ani presne nevim...
-
Mihnul sem se kolem projektu kde meli na confluence na titulni strance pro vyvojare napsano: Pokud lehne build tak pouzijte tyhle prikazy na pozabijeni vsech gradle deamonu a podprocesu ktere to vytvorilo a zkuste to znova.
A jeden z vyvojaru tam mel napsanej script v antu kterej presne tohle delal.... :-)
A jeste si pamatuju projekt kde se poustel script kterej poustel maven... ten vnitrne poustel pomoci antrun pluginu ant.... ten sam poustel nekolik bash a perl scriptu... jeden z tech perl scriptu myslim generoval a poustel nejaky make fily... a jeden z tech scriptu dokonce znova poustel maven...
A ja mel na starosti to znova uchodit po migraci repozitaru a build serveru.... Krasne straveny tyden :-D
Pointa.... ani presne nevim...
Pointa = šedá je toerie, zelený je strom praxe :D
-
To je prave problem to nechat na seniornich lidech. Trochu ty seniorni java backend programatory podeziram, ze znaji jen svatou trojici - java8 / maven / spring a tim koncej. Vyhovuje jim to. Coz by bylo dobre... Jen se bojim, ze jim to vyhovuje, protoze v tom delaji dlouho... Ja jsem v teto oblasti (java backend) pomerne novy, ale vyrobe SW se uz venuju docela dlouho a odzkousel jsem si mnoho jinych veci.
Nevěřím, že by neznali Gradle - Gradle není žádná hipsteřina. Pokud by znali jen java 8, Maven a Spring tak je to pro projekt IMHO problém. Jako ne že by nemohli být užiteční, ale přibral bych do týmu ještě někoho dalšího, kdo má up-to-date znalosti a kdo pomůže, aby byl kód přiměřeně moderní.
Proč to ale neřešíte přímo s nima?
Tak tomu verte, ze jsou senior java developeri, kteri si Gradle nikdy nevyzkouseli. Ja si asi hlavne chtel potvrdit, ze nejsem zadny hipster. A taky se dozvedet jak ten Maven/Gradle vnima sirsi spektrum lidi. A me toto vlakno pomohlo. Dostal jsem nejake podmety si to cele znova prebrat a popremyslet nad tim. Treba co jsem si odnesl - koukat se na Maven jako na "automation tool" je chyba.
-
Mihnul sem se kolem projektu kde meli na confluence na titulni strance pro vyvojare napsano: Pokud lehne build tak pouzijte tyhle prikazy na pozabijeni vsech gradle deamonu a podprocesu ktere to vytvorilo a zkuste to znova.
A jeden z vyvojaru tam mel napsanej script v antu kterej presne tohle delal.... :-)
A jeste si pamatuju projekt kde se poustel script kterej poustel maven... ten vnitrne poustel pomoci antrun pluginu ant.... ten sam poustel nekolik bash a perl scriptu... jeden z tech perl scriptu myslim generoval a poustel nejaky make fily... a jeden z tech scriptu dokonce znova poustel maven...
A ja mel na starosti to znova uchodit po migraci repozitaru a build serveru.... Krasne straveny tyden :-D
Pointa.... ani presne nevim...
Jo, tedka si vzpominam ze si tu mel vlakno "Nový projekt vs. cizí kód". Jsou silenosti v obou pripadech. Pritom skoro na kazdem projektu je nekdo kdo ma visacku "senior". Ze se nableje business logika do kodu, az to je neudrzitelne. To nejak dokazu pochopit. Ale takovehle, rekneme, obecne veci business logikou absolutne nezatizene. Achjo.
-
... koukat se na Maven jako na "automation tool" je chyba.
Jako automation tool se dá (vy|zne)užít kdeco. Třeba mnou zmíněný GNU make je na to skvělý, jen parametrizace trochu kulhá. Ovšem třeba s Gitem se dá také docela slušně vyblbnout například při spouštění integračních testů. Jednotkové testy si spouštím přes make přímo z Vimu.