[Java lista] eclipse-jee-europa-winter-win32, Ant, Java EE 5

István Viczián viczian.istvan at gmail.com
2008. Júl. 7., H, 08:14:50 CEST 

Szia,

No, ez már szép, és már hasznos is, köszönöm szépen, emésztenem kell!
Amit kérdezni akarok első átfutás után, hogy akkor sima fejlesztésnél
és unit tesztelésnél felejtsem el a Maven-t importáljam a
fejlesztőeszközbe, és azzal fordíttassak, futtassak, ebből a Maven-t
hagyjam ki? Mert akkor nekem ez nem volt tiszta.
Szóval eddig is így ment, SVN checkout, open project. Mivel a NetBeans
kapásból Ant-tal dolgozott, ezért a legtöbb probléma meg is volt
oldva.

Ami kérdezni akarok, leírtad, hogy hogyan, kérlek, ha van időd, azt is
írd le a gyakorlati tapasztalatod alapján, hogy miért? Mik azok a
feature-ök, amiért megéri használni, tapasztalatod alapján fontossági
sorrendben. A marketing rizsát ismerem, hogy miért jó, de a
tapasztalat érdekelne.

Viczi

2008/7/3 Tamás Cservenák <tamas at cservenak.net>:
> Ok, bocs, felreertes ne essek!
>
> Nem hitvitat akartam kezdeni :)
>
> Csak azok az ervek melyeket felhoztatok, nem helytalloak, ennyi.
>
> - A maven csak a "clean" goal kiadasakor "fordít, importál, másolgat,
> generál". De ez ervenyes minden build tool-ra, mint az Ant, Make, stb. Clean
> nelkul ezt _nem_ teszi egyik sem.
>
> - A maven "live" fejlesztesre esszeru a projektet eclipse-be "importalni",
> erre kulonbozo modok lehetsegesek: m2eclipse, q4e, maven-eclipse-plugin vagy
> kezi. Egyes megoldasok meg a Junitok eclipse-szeru futtatasara is
> lehetoseget adnak ("ugy dolgozol a projekten mint barmely mas eclipse
> projekten"). Nem kell minden kodmodosulas utan CLI es "mvn clean install".
> Mert az ugy _tenyleg_ hosszu :)
>
> - A "mindent lépten-nyomon újra össze akar szedni" csak ket fele keppen
> tudom elkepzelni: SNAPSHOT depsjeid vannak, es a recheck policy valami
> nagyon kicsi (tehat allitsd at), VAGY minden egyes build elott kitorlod a
> local repo-t? (Ilyet is lattam mar advanced juzereknel) :) Mas magyarazatot
> hirtelen nem tudok.
>
> - "importált repository elemet mondjuk egy saját modulra", itt gondolom
> "deployed artifact"-ra gondoltok. Hat igen, nem egyszeru, de megteheto
> tobfelekeppen: a) hasznald ugyanazt a nevet, de "kereszteld at" a verziot,
> pl. junit:junit:3.8.2 helyett install a local repo-ba mint
> junit:junit:3.8.2-rev123212-super-modified es modositsd a POM-ot. Ennyi.
> Termeszetesen, ezzel a build csak "kontrollalt" kornyezetben lesz buildable.
> Vagy, b) telepits MRM-t (Artifactory, Archiva, Nexus, Proximity), es
> "spoof"-old a public repo-t a sajatoddal.
>
> - "nekem viszont a könnyű debug miatt inkább a forráskódból generált
> változatot" -- roviden: use classifiers. Tehat deploy-olj pl. egy "sima" es
> egy "debug" classified artifact-ot. Te hasznald a "debug"-ot.
>
> - "fél világ összes különböző ilyen-olyan konfig-szerű állományát át kell
> írni hozzá" -- a fenti kettohoz egy-egy sor tartozik a POM-ban (kiveve a b)
> esetet ahol semmi sem valtozik a POMban)
>
> Es visszakerdezek/feleselek (sic!):
>
> - "Módosítasz egy sort az egyik projektben, és ki akarod próbálni". Ez alatt
> mit ertunk? JUnit? Vagy "QA" tesztet? Vagy... (azt amire nem merek
> gondolni?)  ;)
>
> - A Mergere konyv mar lassan ket eves (olv. elavult), es a Mergere is
> megszunt mar. A Sonatype az ropogos es friss :)
>
> - A Maven egyik kidobando feature-ja a site, pedig pont ezt emlited. A
> fejlesztok idokozben rajottek, hogy van sokkal jobb tool is, pl. XSite. A
> mvn site az valojaban a reportok miatt erdekes (javadoc, xref, emma,
> findbugs, stb), a csilivili szajtokat XSite-ban tessek csinalni (ja, van
> maven pluginja ;)
>
> - Es vegul, amit tul sokan nem akarnak megerteni: a Maven az nem egy CLI
> build tool, hanem _infrastruktura_. Tehat, letoltod az apache.org-rol es
> belovod, buildelgetsz itt es ott. Ez mukodik nalad otthon es egy
> garazscegben (1-2 szemelyes). De nem egy rendes helyen. Nem am. Oda
> infrastruktura kell. Ez van sajna. Fabol vaskarikat.... kivaltani ezeket
> elegge nehez es veszelyes.
>
> - Continous integration? Headless build? Ezekre a Maven-t kiveve csak az Ant
> v. (brr, hardcore) Make a jo. Tehat aki kizarolag Eclipse projekteket gyart,
> az felejtse el ezeket (haha, hacsak nem hasznalja a Sonatype Tycho-t :)  LOL
>
>
> Legrovidebben: RTFM ;)
>
>
> Udv,
> T
>
>
>
> 2008/7/2 István Viczián <viczian.istvan at gmail.com>:
>>
>> Kedves Tamás,
>>
>> a Maven komplex, és elegendő időt töltöttem a megismerésével, az
>> egyébként nagyon jó, és nem Maven-eseknek is erősen ajánlott Better
>> Builds with Maven (http://www.exist.com/?q=node/151), szintén ingyenes
>> könyv nagy részét végigolvastam. Erősen használtam, órákat
>> foglalkoztam csak a build folyamattal, és nem hozta meg azokat az
>> előnyöket, amiket vártam tőle. Úgy gondolom, projektje, embere,
>> ízlése, stb. válogatja, hogy mikor jó használni és mikor nem. Én egy
>> olyan projektben vettem részt, amelyet kevesen fejlesztettünk, egy
>> helyen, egy modulból állt, azaz pont nem olyan környezetben
>> használtuk, ahol az erősségeit kihasználhattuk, és csak a
>> robosztusságából eredendő hátrányaival találkoztunk. Opensource,
>> distributed fejlesztésnél, ahol csilli-villi honlap generálását is ki
>> lehet használni a sok plugin-nek, vagy ahol sok modul van, bonyolult
>> függésekkel, bizonyára sokkal hasznosabb.
>> Mi konkrét érveket hoztunk fel, hogy miért nem tetszik (belátom,
>> erősen szubjektívek lehetnek), de sajnos az erre jött "béna vagy
>> hozzá, ezért nem működik" érv számomra kevés a meggyőzéshez. És ha egy
>> könyv és több óra alkotás után nem lehet belőle kézreálló, és ismétlem
>> projektre/emberre szabott megoldást kihozni belőle, akkor ez is egy
>> érv lehet a használata mellett vagy ellen?
>>
>> Szóval próbáljátok ki, és döntsétek el, hogy tetszik, vagy nem.
>> Tanulni biztosan fogtok belőle, mert rengeteg jó ötlet van, amit át is
>> vettem belőle projekt szervezésileg.
>>
>> De szerintem ez hitvita, olyan, hogy a JAR-ok legyenek-e repo-ban,
>> vagy legyen SNV-ben. Kinek mi tetszik. Én elmondtam, nekem mi. :)
>>
>> Viczi
>>
>> 2008/7/2 Tamás Cservenák <tamas at cservenak.net>:
>> > Ugy latom, konnyebb "nem akarni ismerni", mint megismerni :)
>> >
>> > Btw, a felhozott "indokok" melyeket mindketten "megosztjatok" nem
>> > helytalloak (vagy misuse vagy misconfiguration eredmenye), es foleg a
>> > Maven
>> > nem-elegge-ismeresebol fakadnak. Sajnos, sokan, foleg felenk "ex
>> > catedra"
>> > meg sem akarja ismerni, pedig....
>> >
>> > Az igaz, hogy a maven complex (vagy annak tunik az elejen), de mostmar
>> > van
>> > hozza konyv is (ja, free!):
>> >
>> > http://www.sonatype.com/book/index.html
>> >
>> > Udv,
>> > T
>> >
>> >
>> > 2008/6/18 István Viczián <viczian.istvan at gmail.com>:
>> >>
>> >> Üdv,
>> >>
>> >> idézek a saját levelemből:
>> >> "Maven esetén ez ki van dolgozva, hogy mi hova
>> >> kerüljön, convention over configuration, mint tudjuk. Azt viszont nem
>> >> szeretném bevezetni, van rá pár okom."
>> >>
>> >> A Maven-ből egyedül ez tetszik. Amit írsz, az meg nem tetszik. Emiatt
>> >> nem is akarom használni, erről nem kell meggyőznöd, de örülök, hogy
>> >> egy véleményen vagyunk. :) Ha repo, akkor inkább ivy. Próbálkoztam egy
>> >> darabig a NetBeans Maven integrációjával, csak rossz tapasztalataim
>> >> vannak, pont a módosítok egy fájlt, percek, míg sima NB projekt esetén
>> >> azonnal, kb 2 hét után álltam vissza, pikk-pakk ment.
>> >> Nem az érdekel igazán, hogy mi nem jó, hanem, hogy mi jó. Eclipse 40
>> >> projekttel, de mi van utána? Hogy csinálsz EAR-t? Ant-ot használsz-e?
>> >>
>> >> Istvánnak válaszolva:
>> >> Oktatást tartok, tudod milyent, ajánlatom még áll. :) Eddig
>> >> NB/Glassfish alapokon ment, most Eclipse/JBoss. A Java EE oktatásnak
>> >> nem része a Maven, időbe sem fér bele, meg amúgy is nehézkesnek
>> >> tartom. Ezért jó erre a célra az előbbi kombó, mert nem az
>> >> infrastruktúra építgetésével telik az idő, plugin letöltések, konfig
>> >> hegyek, hanem azonnal lehet nyomni az elméletet és azonnal kipróbálni.
>> >> Itt tényleg nagyon fontosak a lehető leggyorsabb iterációk, és a
>> >> lehető legkevesebb a feltételezett háttértudás, szemben egy őrült nagy
>> >> projekttel, ahol nem biztos, hogy az elsődleges cél.
>> >>
>> >> Nem akarok hitvitát indítani, használjon mindenki, amit szeret, de
>> >> oktatni az előbbi kombináció nagyságrendekkel jobb. Persze lehet
>> >> érvelni, hogy akkor a diák nem tudja meg, hogy mi zajlik a háttérben,
>> >> de ez egyrész nem igaz, másrészt próbáljatok belesűríteni mindent egy
>> >> hétbe, mondjuk Maven-t és társait, az összes Java EE technológiát, ezt
>> >> kipróbálni egy társaságon, lemérni a hatását, és majd ezután várom az
>> >> ellenérveket. Az előbbi kombinációban ez hatásos volt.
>> >>
>> >> Szóval a kérdés még mindig az, hogy van-e valami kvázi standard arra,
>> >> hogy hogyan kell ezekkel az eszközökkel egy komoly projekt hierarchiát
>> >> összeállítani, és Ant-tal fordítani, szabvány könyvtárnevek,
>> >> elhelyezések, ant target-ek ilyesmi. Én nem találtam, ezért kérdezlek
>> >> Titeket. Ti is sajátot hoztok össze? Mint az általam olvasott könyvek
>> >> és blog-okban szereplő mintapéldák?
>> >>
>> >> Viczi
>> >>
>> >> 2008/6/18  <istvan.ketler at lhsystems.com>:
>> >> > Szia,
>> >> >
>> >> > képzelj el egy melót, amiben van mondjuk 40 eclipse project - ezek az
>> >> > alkalmazás moduljai. Maven alatt van az egész. Módosítasz egy sort az
>> >> > egyik
>> >> > projektben, és ki akarod próbálni. Na erre a maven mindent jól újra
>> >> > fordít,
>> >> > importál, másolgat, generál. Ez fürge gépen is jó sok perc. Szóval a
>> >> > kis
>> >> > lépések politikájához biztosan nem való.
>> >> >
>> >> > A repository megoldása is biztos nagyon jó ötlet, de nekem nem
>> >> > annyira
>> >> > tetszik, hogy mindent lépten-nyomon újra össze akar szedni.
>> >> >
>> >> > Lecserélni egy importált repository elemet mondjuk egy saját modulra,
>> >> > na
>> >> > az sem egyszerű, a fél világ összes különböző ilyen-olyan
>> >> > konfig-szerű
>> >> > állományát át kell írni hozzá, hibaüzenet meg nincs, csak egyszerűen
>> >> > nem
>> >> > működik, amíg nem tökéletes. Különösen, ha azt akarom, hogy a többiek
>> >> > a
>> >> > repository-ból használják, nekem viszont a könnyű debug miatt inkább
>> >> > a
>> >> > forráskódból generált változatot, na akkor aztán lehet egy darabig
>> >> > játszani.
>> >> >
>> >> > Személy szerint példul ezekért nem szeretem a Mavent, és magamtól
>> >> > soha
>> >> > nem fogom használni. Ha csapatban dolgozol, szerintem egy kicsit
>> >> > inkább a
>> >> > rémálom kategóriába tartozik, különösen a harmadiknak említett
>> >> > tulajdonsága
>> >> > miatt. Akár egyedül, akár csapatban dolgozol, az első tulajdonsága
>> >> > meg
>> >> > szörnyű. Eccerűen szeretek egyszerre keveset módosítani, és azt
>> >> > nyomban
>> >> > kipróbálni, na.
>> >> >
>> >> > Persze lehet, hogy pusztán csak tudatlan vagyok a kezelését illetően,
>> >> > de
>> >> > nem szívesen olvasnék el egy szekérderéknyi irodalmat hozzá, inkább
>> >> > nem
>> >> > használom. Az előnyei jelenleg úgysem kellenek. Meg az is lehet, hogy
>> >> > olyasmire akarom használni, amire nem való (szoftverfejlesztésre,
>> >> > haha).
>> >> > Különben is kényelmesebb ex catedra kijelenteni, hogy Maven suxxx. :)
>> >> >
>> >> > Üdvözlettel,
>> >> >
>> >> > Iván KETLER
>> >> >
>> >> >>
>> >> >
>> >> > Sitz der Gesellschaft / Corporate Headquarters:
>> >> > Lufthansa Systems Hungaria Kft, Budapest
>> >> > Fövarosi Birosag 01-09-463417
>> >> >
>> >> > Geschaeftsfuehrung/ Management Board:
>> >> > Monika Houck
>> >> > -----Original Message-----
>> >> >
>> >> >> From: javalist-bounces at javagrund.hu
>> >> >> [mailto:javalist-bounces at javagrund.hu] On Behalf Of Verhás István
>> >> >> Sent: Wednesday, June 18, 2008 10:32 AM
>> >> >> To: javalist at javagrund.hu
>> >> >> Subject: Re: [Java lista] eclipse-jee-europa-winter-win32,
>> >> >> Ant, Java EE 5
>> >> >>
>> >> >> "Maven esetén ez ki van dolgozva, hogy mi hova kerüljön,
>> >> >> convention over configuration, mint tudjuk. Azt viszont nem
>> >> >> szeretném bevezetni, van rá pár okom."
>> >> >>
>> >> >> Megosztanád? Kiváncsi vagyok.
>> >> >> üdv
>> >> >> vi
>> >> >>
>> >> >>
>> >> >>
>> >> > _______________________________________________
>> >> > Javalist mailing list
>> >> > Javalist at javagrund.hu
>> >> > http://javagrund.hu/mailman/listinfo/javalist
>> >> >
>> >> _______________________________________________
>> >> Javalist mailing list
>> >> Javalist at javagrund.hu
>> >> http://javagrund.hu/mailman/listinfo/javalist
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > ~t~
>> > _______________________________________________
>> > Javalist mailing list
>> > Javalist at javagrund.hu
>> > http://javagrund.hu/mailman/listinfo/javalist
>> >
>> >
>> _______________________________________________
>> Javalist mailing list
>> Javalist at javagrund.hu
>> http://javagrund.hu/mailman/listinfo/javalist
>
>
>
> --
> Thanks,
> ~t~
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>

További információk a(z) Javalist levelezőlistáról