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

[Andras Dobrosi]

Bevallom nem ertem mit mondasz, de engem meggyoztel :)

Andris

2008/7/10 Tamás Cservenák <tamas at cservenak.net>:
> Heh,
>
> gondolom felreertettuk egymast :)
>
> Nem kihagyni, hanem circumvent it.
>
> Vegyuk peldaul az m2eclipse-t (ezt ismerem, mi csinaljuk es termeszetesen
> hasznaljuk is cegen belul).
>
> http://m2eclipse.sonatype.org/
>
> Ez valojaban egy Maven 2.1 "under the hood". Csak eppen "becsomagolja" es
> (most egy mesterkelt szo jon) "eklipszesiti" a maven project-et: source
> folders, goals, stb. Van benne szep POM editor, szep Nexus integracio, stb.
> De minden a mvn futtatasara csapodik le... (csak itt az eclipse JVM-ben fut)
>
> Tehat, amikor te "Clean"-t csinalsz, az majdnem (nem 100%) megegyezik a "mvn
> clean" CLI sorral.
>
> Masik veglet a "mvn eclipse:eclipse" plugin, ami valojaban csak egy "manko",
> mert ugyanezeket probalja elerni azzal hogy ir/frissiti a ".project" es
> ".classpath" fajlokat. De miutan eclipse-ben vagy, valoban semmi kozod a
> Mavenhez.
>
> Tehat, maradjunk annyiban, hogy nem "kihagyod a maven-t", hanem
> "kihagyhatod". De nem kell.
>
> A netbeans 6.x kapasbol dolgozik Maven-nel, Milos Kleint (szinten velunk
> van) a Netbeans integracio "felelose" :)
> http://wiki.netbeans.org/MavenBestPractices
>
> Es vegul, a "final artifact" (az ami a vegtermek) altalaban nem a fejleszto
> gepen keletkezik. A fejleszto gepen leggyakrabban csak "kozbulso" JAR fajlok
> keletkeznek (pl. kulonbozo modulok "vegtermekei"), egy "teljes full
> build-et" fejleszto egyszeruen nem futtat. Mert nem :) Esetleg a projekt
> elejen, mikor "belovi" e projektet es leteszteli azt...
>
> A release artifact-ok valami kontrollalt kornyezetben (tehat az embert
> legjobb kizarni) keletkeznek (CI : continous integration), mint pl. a Hudson
> (http://ci.sonatype.org/). A Hudson "hallgatodzik" a SVN valtozasokra, es
> szukseg szerint legyart egy-egy modult, vagy a teljes projektet
> (opcionalis).
>
> Es vegul, _mindenki_ a CI altal gyartott "kozponti" JAR-okat hasznalja
> fuggosegkent (pl. a nexus-ba deploy, majd onnen a fejlesztok szivjak), igy
> teszed lehetove, hogy egy 15 modulbol allo projekten barki fokuszalt modon
> pl. csak 1 modult csekkel ki, es azonnal buildelheti, mert a szukseges 6
> dependency-t majd leszivja neki a maven (es azokat a CI kontrollalt modon
> gyartotta le es deployolta a Nexusra). Tehat meg a fejlesztok is izolaltak,
> es nincs kavar hogy ki mit kell hogy csinaljon (precondition), mert
> valojaban a modulok grafjanak bermely pontjaba "beugorhatsz", hisz minden a
> Nexusrol leszivhato, mert a CI mar legyartotta neked.
>
> Hrm, most veszem eszre: nexus -> remote repo, nem kotelezoen nexus :)
>
> Na, mostmar elfogyott a so:r, mentem :)
>
> ~t~
>
> 2008/7/7 István Viczián <viczian.istvan at gmail.com>:
>>
>> 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
>> >
>> >
>> _______________________________________________
>> 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
>
>