omluva
Ahoj, Vsem pritomnym se timto omlouvam, ale M$ Outlook to chtel jinak.. JK
Re: eclipse + subversion
Ahoj, ja som skusal oba, subclipse aj subversive a lepsi je subclipse (ale uz presne neviem preco, sa mi zda ze je viac user-friendly). Ono moc velky rozdiel asi nebude ked pouzivaju tu istu kniznicu (http://www.svnkit.com/ vid kto to pouziva), ktoru pouziva aj IDEA. 1, Ten problem s rychlostou - mozno nie je problem. Aka vekla je ta nova kopia? Mate v repo aj kniznice? Alebo aky je server alebo v pripojenie(ak to nie je LAN). Skusil by som to porovnat s inym klientom. Totiz v eclipse to funguje tak, ze sa to najprv nataha a az potom processuje. 2, jasne ze ide, to je pure java 3, ano ma 4, ano ma 5, no tu by som sa drzal knizky http://svnbook.red-bean.com/ A k tomu refactoringu, neviem preco by bol potrebny comit po premenovani - aky je dovod? Jedine ze by vznikal nejaky konflikt, ale podla mna nevznika. A este na zaver by som poznamenal, ze mne osobne sa paci produkt SmartCVS. JE aj SmartSVN http://www.syntevo.com/smartsvn/highlights.jsp. Je tu odlisni pristup k zobrazeniu, ako inde. PS:Ludia co vivijaju subclipse su ochotny a radi zlepsuju svoj produkt, koli nam dorobili podporu pre eclipse-symlinky. vladimír karásek wrote: Dobrý den, chci se zeptat jestli někdo má zkušenosti s vývojem větších (nebo středních) projektů v kombinaci eclipse a subversion. Jsme ochotní zaplatit za odborné konzultace. Co mně zajímá: 1. Rychlost satažení nové kopie projektu z repository 2. Možnost používat kleinty na platformách Windows, Linux a Solaris 3. Možnost procházet historii, porovnávat, upravovat. To vše nějakým inteligentním způsobem. Takže to asi bude muset být Eclipse plugin. 4. Větvení a spojování. 5. Struktura repository. Náš současný stav. Máme asi 30 projektů, které jsou vzájemně závislé. Používali jsme až donedávna CVS a vedení se rozhodlo, že je na čase použít něco vyspělejšího. Subversion slibovalo hodně ale přechod je více meně "pain in the ass". Největší problém asi bude nalezení (konfigurace) Subversion klienta pod Eclipse, momentálně používáme eclipse plugin Subversive, jeho poslední verzi. Přišli jsme na to, že pro rychlejší práci je třeba odškrnout několik checkboxu v nastavení, ale to nám pořád nestačí. Momentálně stažení nové kopie z repository trvá 10 minut. Prucejeme metodikou XP programování. Často děláme refactoring. Nevjětším problémem je situace, kdy musíme přejmenovat class a pak ho nějak dál upraovat. Jenže udělat v daný moment nemůžeme. Musíme přejmenovat, udělat commit a pak můžeme dělat druhou operaci. Což je velice nepohodlné. Myslím si, že to musí jít nějak snadněji. Ví někdo jak?
Re: eclipse + subversion
> PS:Ludia co vivijaju subclipse su ochotny a radi zlepsuju svoj produkt, > koli nam dorobili podporu pre eclipse-symlinky. Navic subversive se presunul pod kridla eclipse (http://www.eclipse.org/proposals/subversive/) a co jsem (pred casem) v mailink listu subclipse vycetl, tak se snad bude spoluprace obou komunit sblizovat ... uvidime -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
Re: eclipse + subversion
Subversive je daleko mladsi projekt nez Subclipse, takze ma sem tam mouchy, zatim hlavne co se tyce performance na default nastaveni, ale ja sem na nej velice rad presedlal, Sublicpse vyvoj se mi zda pomalej a vim ze sem obecne ze Subclipse nemel dobrej pocit. Ciste subjektivni pohled. Subversive je oproti tomu o dost aktivnejsi a jak uz zde padlo, stehuje se pod kridla Eclipse Foundation a to uz podle me taky neco znamena. Ja zvedam ruku za Subversive. Tomas Studva wrote: Ahoj, ja som skusal oba, subclipse aj subversive a lepsi je subclipse (ale uz presne neviem preco, sa mi zda ze je viac user-friendly). Ono moc velky rozdiel asi nebude ked pouzivaju tu istu kniznicu (http://www.svnkit.com/ vid kto to pouziva), ktoru pouziva aj IDEA. 1, Ten problem s rychlostou - mozno nie je problem. Aka vekla je ta nova kopia? Mate v repo aj kniznice? Alebo aky je server alebo v pripojenie(ak to nie je LAN). Skusil by som to porovnat s inym klientom. Totiz v eclipse to funguje tak, ze sa to najprv nataha a az potom processuje. 2, jasne ze ide, to je pure java 3, ano ma 4, ano ma 5, no tu by som sa drzal knizky http://svnbook.red-bean.com/ A k tomu refactoringu, neviem preco by bol potrebny comit po premenovani - aky je dovod? Jedine ze by vznikal nejaky konflikt, ale podla mna nevznika. A este na zaver by som poznamenal, ze mne osobne sa paci produkt SmartCVS. JE aj SmartSVN http://www.syntevo.com/smartsvn/highlights.jsp. Je tu odlisni pristup k zobrazeniu, ako inde. PS:Ludia co vivijaju subclipse su ochotny a radi zlepsuju svoj produkt, koli nam dorobili podporu pre eclipse-symlinky. vladimír karásek wrote: Dobrý den, chci se zeptat jestli někdo má zkušenosti s vývojem větších (nebo středních) projektů v kombinaci eclipse a subversion. Jsme ochotní zaplatit za odborné konzultace. Co mně zajímá: 1. Rychlost satažení nové kopie projektu z repository 2. Možnost používat kleinty na platformách Windows, Linux a Solaris 3. Možnost procházet historii, porovnávat, upravovat. To vše nějakým inteligentním způsobem. Takže to asi bude muset být Eclipse plugin. 4. Větvení a spojování. 5. Struktura repository. Náš současný stav. Máme asi 30 projektů, které jsou vzájemně závislé. Používali jsme až donedávna CVS a vedení se rozhodlo, že je na čase použít něco vyspělejšího. Subversion slibovalo hodně ale přechod je více meně "pain in the ass". Největší problém asi bude nalezení (konfigurace) Subversion klienta pod Eclipse, momentálně používáme eclipse plugin Subversive, jeho poslední verzi. Přišli jsme na to, že pro rychlejší práci je třeba odškrnout několik checkboxu v nastavení, ale to nám pořád nestačí. Momentálně stažení nové kopie z repository trvá 10 minut. Prucejeme metodikou XP programování. Často děláme refactoring. Nevjětším problémem je situace, kdy musíme přejmenovat class a pak ho nějak dál upraovat. Jenže udělat v daný moment nemůžeme. Musíme přejmenovat, udělat commit a pak můžeme dělat druhou operaci. Což je velice nepohodlné. Myslím si, že to musí jít nějak snadněji. Ví někdo jak?
Re: eclipse + subversion
Pozeral som sa na ten refactoring. Operacia rename je realizovana cez remove a add. Cize stary subor sa vymaze a novy(t.j. stru s novym menom) sa nastavy ako add. Potom ten novy subor modifikujete. A tu vyzera ze je problem, ale neviem preco. Som to skusal a neslo mi to comitnut. Tak som musel ten subor revertnut(zrusit add) a znovu spravit add. Potom to islo comitnut. vladimír karásek wrote: Dobrý den, chci se zeptat jestli někdo má zkušenosti s vývojem větších (nebo středních) projektů v kombinaci eclipse a subversion. Jsme ochotní zaplatit za odborné konzultace. Co mně zajímá: 1. Rychlost satažení nové kopie projektu z repository 2. Možnost používat kleinty na platformách Windows, Linux a Solaris 3. Možnost procházet historii, porovnávat, upravovat. To vše nějakým inteligentním způsobem. Takže to asi bude muset být Eclipse plugin. 4. Větvení a spojování. 5. Struktura repository. Náš současný stav. Máme asi 30 projektů, které jsou vzájemně závislé. Používali jsme až donedávna CVS a vedení se rozhodlo, že je na čase použít něco vyspělejšího. Subversion slibovalo hodně ale přechod je více meně "pain in the ass". Největší problém asi bude nalezení (konfigurace) Subversion klienta pod Eclipse, momentálně používáme eclipse plugin Subversive, jeho poslední verzi. Přišli jsme na to, že pro rychlejší práci je třeba odškrnout několik checkboxu v nastavení, ale to nám pořád nestačí. Momentálně stažení nové kopie z repository trvá 10 minut. Prucejeme metodikou XP programování. Často děláme refactoring. Nevjětším problémem je situace, kdy musíme přejmenovat class a pak ho nějak dál upraovat. Jenže udělat v daný moment nemůžeme. Musíme přejmenovat, udělat commit a pak můžeme dělat druhou operaci. Což je velice nepohodlné. Myslím si, že to musí jít nějak snadněji. Ví někdo jak?
Re: eclipse + subversion
Moment, nekdo implementuje v subversion rename souboru jako delete + add?? To od nej neni moc hezke, protoze tim ztracite historii, od toho je operace move, tj. i rename. > Pozeral som sa na ten refactoring. Operacia rename je realizovana cez > remove a add. Cize stary subor sa vymaze a novy(t.j. stru s novym menom) > sa nastavy ako add. Potom ten novy subor modifikujete. A tu vyzera ze je > problem, ale neviem preco. Som to skusal a neslo mi to comitnut. Tak som > musel ten subor revertnut(zrusit add) a znovu spravit add. Potom to islo > comitnut. Je pravda, ze jsem mel problem s presouvanim nove vytvorenych souboru v kombinaci s novymi adresari, ale opet problem byl jenom v adresarich, tj. stacilo commitnout adresare a ne jednotlive soubory ... -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
Re: eclipse + subversion
. 1, Ten problem s rychlostou - mozno nie je problem. Aka vekla je ta nova kopia? Mate v repo aj kniznice? Alebo aky je server alebo v pripojenie(ak to nie je LAN). Skusil by som to porovnat s inym klientom. Totiz v eclipse to funguje tak, ze sa to najprv nataha a az potom processuje. Rychlost je 10 minut pro stazeni asi 40 projektu s celkovou velikosti cca 350MB na disku. Server ja na LAN, takze v siti problem neni. 2, jasne ze ide, to je pure java V subversive si muzu vybrat co chci pouzivat. Mam na vyber tyto moznosti: - Native JavaHL (svn: 1.4.2 (r22196) jni 0.9.0) - SVN Kit - Subversive Default (JavaSVN 1.0.4 (http://tmate.org/svn)) jsme se priklonili k JavaHL protoze je mnohem rychlejsi nez pure Java. A este na zaver by som poznamenal, ze mne osobne sa paci produkt SmartCVS. JE aj SmartSVN http://www.syntevo.com/smartsvn/highlights.jsp. Je tu odlisni pristup k zobrazeniu, ako inde.
Re: digitální certifikát
Ne, tak to není. Podpis kódu je speciální účel, který by musel být uveden v certifikátu. Je to jiný účel než obecné podpisy nebo prokazování identity. Pokud vím, žádná z akreditovaných CA v ČR vám nevydá certifikát, který by měl podpis kódu mezi svými účely. Honza Dvořák Tomáš Procházka napsal: Ahoj, odpovídám na zprávu ze čtvrtka, 25. ledna 2007, kterou Jan Dvořák napsal(a) v 15:07:34: Tohle je o ničem :-( PostSignum tam má na výběr buďto osobní a nebo serverový certifikát, tak bych čekal, že podepisování osobního kódu by mohlo patřit do té kategorie osobní. --- Původní zpráva --- Odesilatel: Jan Dvořák <[EMAIL PROTECTED]> Předmět: digitální certifikát Datum: 25. ledna 2007, 15:07:34 (GMT +0100) Přílohy: msgid:[EMAIL PROTECTED] J> Ahoj, J> Kvalifikovany certifikat od PostSignum (stejne jako od zbyvajicich dvou J> akreditovanych CA v CR) nema ve svych ucelech podpis kodu. J> I kdyby mel, korenove certifikaty techto CA jsou JRE-ckum i prohlizecum J> vesmes nezname, takze se k takto podepsanym apletum budou chovat jako k J> podezrelemu kodu. J> Leda byste presvedcil vase uzivatele, aby si hodili korenovy certifikat J> mezi duveryhodne CA, ale to podle mne zacne delat jen zlomek z nich, a J> uspesne dokonci jen zlomek z toho zlomku. J> Pro nasi webstartovanou aplikaci jsme nakonec sahli po certifikatu pro J> podpis kodu od Thawte. J> Nebyl uplne levny. Firma to unesla, ale jako jednotlivec bych sel cestou J> Thawte Free Mail certifikatu. J> Podle mne potrebujete certifikaty dva: jeden pro zabezpeceny styk se J> statni spravou, a druhy pro podpis kodu. J> Mimochodem, nevite nekdo jeste o jine CA nez Thawte a Verisign, ktere by J> vydavaly certifikaty pro podpis javoveho kodu a mely korenovy certifikat J> mezi duveryhodnymi? J> Honza Dvorak J> MathAn Praha J> Tomáš Procházka napsal: Ahoj, odpovídám na zprávu ze čtvrtka, 25. ledna 2007, kterou Rastislav Rehak napsal(a) v 10:39:06: No, já bych měl konkrétně zájem asi o http://qca.postsignum.cz/, je to skoro za pakatel a nemusím objíždět žádné notáře, což by časově vyšlo stejně dráž. Ale to zda mají ty certifikáty podepsané někým, koho Java považuje za důvěryhodného je určitě docela rozhodující fakt. Má někdo zkušenosti přímo s tím? Pro server certifikát skutečně nechci, ale pro podepisování emailů, styk s úřady a podepisování aplikací ano. --- Původní zpráva --- Odesilatel: Rastislav Rehak <[EMAIL PROTECTED]> Předmět: digitální certifikát Datum: 25. ledna 2007, 10:39:06 (GMT +0100) Přílohy: msgid:[EMAIL PROTECTED] R> Pre zaciatok by som vyskusal Thawte Free Mail certificate. Ked sa R> prihlasite do TFM mozete si nechat vygenerovat mailovy certifikat vhodny R> aj na podpisovanie kodu. R> Tento certifikat bude mat meno drzitela "Thawte free mail member" co nie R> je zrovna to prave, ale na druhej strane je root CA je importovana v R> JRE, takze to funguje. R> Dalej je mozne navstivit aspon dvoch notarov zo siete Thawte Web of R> Trust overit totoznost, ziskat aspon 50 bodov a potom si budete moct R> vygenerovat tento certifikat na vase meno. Tak daleko som sa este R> nedostal, lebo okolo mna je malo notarov a nechce sa mi cestovat len pre R> certifikat. Mozno ked pojdem do Prahy tak to vyskusam. R> Popis najdete tu: http://www.dallaway.com/acad/webstart/ aj ked linky R> sa uz zmenili. R> Na slovensku existuje system CA ( napriklad EVPU Nova Dubnica ) ktora R> vydava certifikaty na komunikaciu so statnou spravou. Tieto certifikaty R> NEBRAT. Su uplne k nicomu, lebo ich root je NBU ( to su ti co maju heslo R> nbusr123 ) a tento pravdaze nie je nainstalovany v ziadnom JRE alebo R> browsery. Tazko presvedcite cloveka na druhom konci sveta, aby si ich R> certifikat importoval do trusted storu. R> Bye Ra100 R> Tomáš Procházka wrote: Zdravím Chci se jen ujistit. Potřebuji si pořídit digitální certfikát mimo jiné také pro podepisovaní java aplikací. Je potřeba při pořízení dávat na něco pozor, je potřeba něco speciálního? Já myslím, že ne, už párkrát jsem s certifikáty pracoval a nikdy jsem problém neměl. Jen mi není jasné to, proč se ty certifikáty ukládají na tolik míst. Něco je v C:\Documents and Settings\Tomas\.keystore a přes to GUI v ovladácích panelech se to přidává se zase někam jinam :-( Jo a ještě jedna věc. Když podepíšu applet a certifikát vyprší bude to dál fungovat nebo budu muset pokaždé všechny své aplikace znovupodepisovat. Podle mě by to mělo být důležité datum podpisu. Datum: 20:08:1224. ledna 2007 Konec původní zprávy
Tomcat, mssqlserver.jar
Dobry den, snazim se pripojit svoji aplikaci ktera bezi v Tomcat kontejneru na MsSQL server. Problem je ten, ze nejsem schopen donutit tomcat, aby nacetl knihovnu mssqlserver.jar Vsechny moje pokusy konci touhle hlaskou: Chyba, Error: Connect errorCannot load JDBC driver class 'com.microsoft.jdbc.sqlserver.SQLServerDriver' [Ljava.lang.StackTraceElement;@e637f0 Pritom, ta sama aplikace mi na druhem serveru bezi uplne bez problemu. Na obou serverech bezi instalace Tomcat 5.5. Na obou jsou uplne stejne skopirovane adresare tomcatu. Na bou jsou uplne stejne adresare te aplikace. Na obou jsou i identicke verze javy. Presto mi tomcat odmita nacist tu tridu. Ani na jednom serveru neni nstavena systemova promena CLASSPATH. Jsem fakt v koncich, tohle naprosto nechapu. Nevite jak donutim ten kontejner at tu knihovnu nacte? Lukas "benzin" Benda
Re: Tomcat, mssqlserver.jar
A kde ten jar je ? Pokud ma DataSource vyrabet tomcat, musi byt v common/lib/, pokud sama aplikace, tak bud v shared/lib/ nebo ve WEB-INF/lib. Makub Lukáš Benda wrote: > Dobry den, > > snazim se pripojit svoji aplikaci ktera bezi v Tomcat kontejneru na MsSQL > server. Problem je ten, ze nejsem schopen donutit tomcat, aby nacetl knihovnu > mssqlserver.jar > > Vsechny moje pokusy konci touhle hlaskou: > > Chyba, Error: Connect errorCannot load JDBC driver > class 'com.microsoft.jdbc.sqlserver.SQLServerDriver' > [Ljava.lang.StackTraceElement;@e637f0 > > Pritom, ta sama aplikace mi na druhem serveru bezi uplne bez problemu. Na > obou > serverech bezi instalace Tomcat 5.5. Na obou jsou uplne stejne skopirovane > adresare tomcatu. Na bou jsou uplne stejne adresare te aplikace. Na obou jsou > i identicke verze javy. Presto mi tomcat odmita nacist tu tridu. Ani na > jednom serveru neni nstavena systemova promena CLASSPATH. Jsem fakt v > koncich, tohle naprosto nechapu. Nevite jak donutim ten kontejner at tu > knihovnu nacte? > > Lukas "benzin" Benda -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 --
Workflow enginy
Dobrý den, rád bych se zeptal na Vaše názory a zkušenosti ohledně workflow enginů v javě. Jaký zvolit jazyk pro definování procesu XPDL, BPEL nebo jiný, a podobně. Procesy, které bych chtěl modelovat, nejsou extrémně složité, kolem 20 stavů. Zatím jsem prozkoumával produkt Enhydra Shark, ale nejsem s ním moc spokojen přijde mi příliš komplikovaný. Zajímavé se mi zdálo např. jBPM od JBoss. Předem děkuji za odpověď Martin Chalupa
CZJUG 31.1. - Spring 2.0, Java Persistence API a navsteva vyvojaru javac
Ahoj, dovoluji si Vás pozvat na další setkání českých uživatelů Javy na ČVUT v posluchárně K1 na Karlově náměstí dne 31.1. v 18:00. Tentokrát nás čekají přednášky v češtině a slovenštině, a to na témata Spring 2.0 a Java Persistence API. Zde jsou abstrakty přednášek: 1. Roman Pichlík - Spring 2.0 Spring 2.0, představení celého konceptu a hlavních myšlenek. Nové vlastnosti verze 2.0 (extensible configuration - annotation, AOP via AspectJ, scopes, Tiger atd.), srovnání klíčových částí s J2EE 5, podpora ve vývojářských nástrojích. 2. Martin Krajčí - Java Persistence API The Java Persistence API (JPA) simplifies the programming model for entity persistence. It provides cleaner, easier, standardized object-relational mapping. Addresses most typical specifications through annotation defaults. Support for inheritance, polymorphism, and polymorphic queries. JPA can be used outside or inside J2EE container with pluggable, third-party persistence providers Na poslední chvíli se nám také podařilo zařadit do programu vývojáře Java Compileru (javac), kteří budou mít kratší prezentaci a Q&A v závěrečné částí setkání. Prezentovat budou hlavní vývojář javac Peter Ahe (http://blogs.sun.com/ahe) a jeho kolega Lubomir Litchev. -Roman Strobl P.S. Budeme rozdávat baťůžky z konference Javapolis a jelikož se nám ochlazuje tak i jednu bundu s logem Java.
Re: eclipse + subversion
Jiri Mares wrote: Moment, nekdo implementuje v subversion rename souboru jako delete + add?? To od nej neni moc hezke, protoze tim ztracite historii, od toho je operace move, tj. i rename. Ten Add není obyčejný Add, ale "Add s plusem ve čtvrtém sloupečku", který si s sebou nese historii, tj. SVN ví, že předtím to byl původní soubor. Alespoň můj SVN klient takto na "svn mv" funguje, tak Subclipse to snad dělá stejně. (Původně jsem psal o druhém sloupečku, omlouvám se.) A mezi přesunem a commitem by se ten nový soubor měl dát normálně poeditovat, pak se A změní na M. Docela pěkně je to popsáno tady: http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.examine.status A + moved_dir # added with history of where it came from M + moved_dir/README # added with history and has local modifications Je to hlavně v tom odstavci, co začíná "The fourth column will only show whitespace or a + which means..." Jarda
Re: eclipse + subversion
Dobrý den, asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta? Všechno je v něm rychlejší a hromadné přidávání souborů taky zvládne v pohodě - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby je úplně jedno co které IDE podporuje za pluginy. K dotazům: Ad 1: svn checkout je rychlý dostatečně, kopii repository děláte stejně jen párkrát a denní svn update je bez problémů. Ad 2: řádkový svn používám v Linuxu, pod Windows taky-tam jsem ze začátku používal http://subversion.tigris.org/. Solaris neumím, stejně jsou to všechno Unixy, takže tam snad bude svn stejné? Ad 3: Historie se nemění, pro hledání mi vždy stačil svn log, svn update do určité revize zpátky, maximálně svn revert, kdy je fakt den blbec a člověk se chce vrátit na začátek. Pro porovnávání souborů - co konkrétně chcete porovávat? Stejně když dělá více vývojářů na jednom souboru, tak máte konflikt, který musíte řešit a pokud naučíte vývojáře podrobně psát zprávy o změnách do logu, tak pro informaci "co se dělalo" log stačí. Klidně ať každý dělá commit několikrát denně s každou změnou, kterou zvlášť popíše. Ad 4: Opět - kolikrát se projekt větví? U nás v Kyberii vždy stačilo mít jednu vývojovou větev (trunk), branch pro odbočky a tags pro finální verze. Minimálně trunk je dobré buildovat automaticky, ale to víte-je to popsáno v XP jako nepřetržitá integrace. Ad 5: Viz. dokumentace k SVN-určitě přečíst, je tam ukázková struktura, velmi to pomůže - http://svnbook.red-bean.com/ Jirka Hradil On 1/29/07, vladimír karásek <[EMAIL PROTECTED]> wrote: Dobrý den, chci se zeptat jestli někdo má zkušenosti s vývojem větších (nebo středních) projektů v kombinaci eclipse a subversion. Jsme ochotní zaplatit za odborné konzultace. Co mně zajímá: 1. Rychlost satažení nové kopie projektu z repository 2. Možnost používat kleinty na platformách Windows, Linux a Solaris 3. Možnost procházet historii, porovnávat, upravovat. To vše nějakým inteligentním způsobem. Takže to asi bude muset být Eclipse plugin. 4. Větvení a spojování. 5. Struktura repository. Náš současný stav. Máme asi 30 projektů, které jsou vzájemně závislé. Používali jsme až donedávna CVS a vedení se rozhodlo, že je na čase použít něco vyspělejšího. Subversion slibovalo hodně ale přechod je více meně "pain in the ass". Největší problém asi bude nalezení (konfigurace) Subversion klienta pod Eclipse, momentálně používáme eclipse plugin Subversive, jeho poslední verzi. Přišli jsme na to, že pro rychlejší práci je třeba odškrnout několik checkboxu v nastavení, ale to nám pořád nestačí. Momentálně stažení nové kopie z repository trvá 10 minut. Prucejeme metodikou XP programování. Často děláme refactoring. Nevjětším problémem je situace, kdy musíme přejmenovat class a pak ho nějak dál upraovat. Jenže udělat v daný moment nemůžeme. Musíme přejmenovat, udělat commit a pak můžeme dělat druhou operaci. Což je velice nepohodlné. Myslím si, že to musí jít nějak snadněji. Ví někdo jak?
Re: eclipse + subversion
asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta? Zdá se mi, že použití řádkového klienta je docela pracné. Už vidím, jak mi řeknou, že další věc bych mohl navrhnout používat vi místo eclipse. 90% programátorů u nás pracuje pod windows, polovina má sice dobré zkušenosti s Linuxem ale ten komfort co dává IDE příkazaová řádka nenahradí. Musím říct, že jsem řádkového klienta ani nevyzkoušel, takže teď jsou to spíš moje představy než zkušenosti. Určitě to napravím. Všechno je v něm rychlejší a hromadné přidávání souborů taky zvládne v pohodě - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby je úplně jedno co které IDE podporuje za pluginy. K dotazům: Ad 1: svn checkout je rychlý dostatečně, kopii repository děláte stejně jen párkrát a denní svn update je bez problémů. Souhlasím, že checkout z řádky musí být rychlejší než z grafického klienta. Ad 2: řádkový svn používám v Linuxu, pod Windows taky-tam jsem ze začátku používal http://subversion.tigris.org/. Solaris neumím, stejně jsou to všechno Unixy, takže tam snad bude svn stejné? Ad 3: Historie se nemění, pro hledání mi vždy stačil svn log, svn update do určité revize zpátky, maximálně svn revert, kdy je fakt den blbec a člověk se chce vrátit na začátek. Pro porovnávání souborů - co konkrétně chcete porovávat? Je to základní funkcionalita, kterou očekávám od "CVS" systemu. Chci mít možnost rychlého kontextového vyhledání v historii, kdy určitá část souboru byla změněna a jak. Mít možnost pohodlně provést refactoring existující verze Stejně když dělá více vývojářů na jednom souboru, tak máte konflikt, který musíte řešit a pokud naučíte vývojáře podrobně psát zprávy o změnách do logu, tak pro informaci "co se dělalo" log stačí. Klidně ať každý dělá commit několikrát denně s každou změnou, kterou zvlášť popíše. Nevím jak moc se to slučuje s XP metodikou, kde hlavní důraz se klade spíš na důkladné testování než na popis co se změnilo a proč se změnilo. Testy musí popisovat fukčnost systému. Ad 4: Opět - kolikrát se projekt větví? U nás v Kyberii vždy stačilo mít jednu vývojovou větev (trunk), branch pro odbočky a tags pro finální verze. Minimálně trunk je dobré buildovat automaticky, ale to víte-je to popsáno v XP jako nepřetržitá integrace. Máme trunk a zatím jednu větev, která se postupně debuguje a připravuje se na release. S více větvemi vzníká problém s podporou těchto větví v případě, že máme opravit bug. Ale určitě budeme muset v průběhu času podporovat minimálně 2 verze produktu.
Re: eclipse + subversion
Dobry den 1. pouziti prikazoveho radku jeste nikoho nezabilo. Ani ve windows. A uprimne receno pouzivame netbeans5.0 a z beta verze tahame svn podporu. Problem mame pri mazani ktere udelam jedine z radku. Pouze pro mazani to delam rucne a taky nevidim ze by se mi zkratily prsty. Dalsim zpusobem ktery tu nedavno nekdo zminoval by bylo pouzit maven nebo ant a naimplementovat si tam svn aby posilalo data na server. Tedy ty zmenene. Metodiku XP pouzivame taky az na drobne vyjimky. 2. Checkout delame jednoznacne pouze z radkoveho klienta. je to totiz skutecne nejrychlejsi zpusob jak ho udelat. Alespon v nasem pripade. Zkousel jsem na unixu rapidsvn, ale ten ma hodne problemu a svn z radku funguje bez problemu. 3. Logovani zmen. Tady mam pocit ze jste nepochopil posledniho prispivatele. On se vubec nebavil o tom ze by nebyl kladen duraz na dukladne testovani. On pouze rekl, ze je potreba vyplnovat do logu co se delalo. Tedy popsat proc jsem to delal. Ve Vasem pripadne uvadim priklad: 1. Pridal jsem novy modul pro spravu faktur 2. Opravil jsem chyby c.555 a c.666 v zadavani dodavatelu do systemu 3. Do modulu pro precenovani zbozi na sklade jsem pridal podporu prohlizeni historie 4. Opravil jsem chybu c.667 ve spravci uzivatelu systemu Pokud chcete namitnout ze to neni v souladu s XP, tak to je mozna pravda, ale takto napriklad pri spadlem internetu zadate zmeny ktere jste dnes implementoval. Tedy nedostupnosti serveru. Rozhodne nesouhlasim s Vasim nazorem, ze je v nem vetsi duraz na testovani nez na to co se provedlo. To podle me pravda neni. Protoze kazdou zmenu dukladne popisujete. 4. Co se tyce svn, tak jsem dlouho vahal a dnes se tlucu do hlavy. Protoze dnes bych ho pouzival i za situace ze bych programoval sam a ne v teamu. Pekny den Petr Burdik Stejně když dělá více vývojářů na jednom souboru, tak máte konflikt, který musíte řešit a pokud naučíte vývojáře podrobně psát zprávy o změnách do logu, tak pro informaci "co se dělalo" log stačí. Klidně ať každý dělá commit několikrát denně s každou změnou, kterou zvlášť popíše. Nevím jak moc se to slučuje s XP metodikou, kde hlavní důraz se klade spíš na důkladné testování než na popis co se změnilo a proč se změnilo. Testy musí popisovat fukčnost systému. On Wed, 31 Jan 2007 00:39:01 +0100, vladimír karásek <[EMAIL PROTECTED]> wrote: asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta? Zdá se mi, že použití řádkového klienta je docela pracné. Už vidím, jak mi řeknou, že další věc bych mohl navrhnout používat vi místo eclipse. 90% programátorů u nás pracuje pod windows, polovina má sice dobré zkušenosti s Linuxem ale ten komfort co dává IDE příkazaová řádka nenahradí. Musím říct, že jsem řádkového klienta ani nevyzkoušel, takže teď jsou to spíš moje představy než zkušenosti. Určitě to napravím. Všechno je v něm rychlejší a hromadné přidávání souborů taky zvládne v pohodě - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby je úplně jedno co které IDE podporuje za pluginy. K dotazům: Ad 1: svn checkout je rychlý dostatečně, kopii repository děláte stejně jen párkrát a denní svn update je bez problémů. Souhlasím, že checkout z řádky musí být rychlejší než z grafického klienta. Ad 2: řádkový svn používám v Linuxu, pod Windows taky-tam jsem ze začátku používal http://subversion.tigris.org/. Solaris neumím, stejně jsou to všechno Unixy, takže tam snad bude svn stejné? Ad 3: Historie se nemění, pro hledání mi vždy stačil svn log, svn update do určité revize zpátky, maximálně svn revert, kdy je fakt den blbec a člověk se chce vrátit na začátek. Pro porovnávání souborů - co konkrétně chcete porovávat? Je to základní funkcionalita, kterou očekávám od "CVS" systemu. Chci mít možnost rychlého kontextového vyhledání v historii, kdy určitá část souboru byla změněna a jak. Mít možnost pohodlně provést refactoring existující verze Stejně když dělá více vývojářů na jednom souboru, tak máte konflikt, který musíte řešit a pokud naučíte vývojáře podrobně psát zprávy o změnách do logu, tak pro informaci "co se dělalo" log stačí. Klidně ať každý dělá commit několikrát denně s každou změnou, kterou zvlášť popíše. Nevím jak moc se to slučuje s XP metodikou, kde hlavní důraz se klade spíš na důkladné testování než na popis co se změnilo a proč se změnilo. Testy musí popisovat fukčnost systému. Ad 4: Opět - kolikrát se projekt větví? U nás v Kyberii vždy stačilo mít jednu vývojovou větev (trunk), branch pro odbočky a tags pro finální verze. Minimálně trunk je dobré buildovat automaticky, ale to víte-je to popsáno v XP jako nepřetržitá integrace. Máme trunk a zatím jednu větev, která se postupně debuguje a připravuje se na release. S více větvemi vzníká problém s podporou těchto větví v případě, že máme opravit bug. Ale u
Re: Workflow enginy
Já jsem začal používat Spring Web Flow - http://www.springframework.org/download. Je k němu pěkně zpracovaná dokumentace. SWF (Spring Web Flow) lze dobře integrovat se Spring Frameworkem (vyzkoušeno), Struts i JSF. Pro SWF existuje i plugin pro Eclipse, který umožňuje vytvření flow v grafickém prostředí - http://www.eclipse-plugins.info/eclipse/plugin_details.jsp?id=765 (mě se jej bohužel nepodařilo rozhodit). Dne Tue, 30 Jan 2007 19:04:35 +0100 Martin Chalupa <[EMAIL PROTECTED]> napsal/-a: > Dobrý den, > > rád bych se zeptal na Vaše názory a zkušenosti ohledně workflow enginů v > javě. > > Jaký zvolit jazyk pro definování procesu XPDL, BPEL nebo jiný, a podobně. > > Procesy, které bych chtěl modelovat, nejsou extrémně složité, kolem 20 > stavů. > > Zatím jsem prozkoumával produkt Enhydra Shark, ale nejsem s ním moc > spokojen přijde mi příliš komplikovaný. Zajímavé se mi zdálo např. jBPM > od JBoss. > > Předem děkuji za odpověď > Martin Chalupa > > -- Vlastimil Vavru Phone: +420 606 228 350 E-mail: [EMAIL PROTECTED]
Re: Workflow enginy
Obavam se, ze jste trochu vedle. tenhle webflow je o "proplouvani uzivatele aplikaci". Workflow je o toku prace (ukolu). A to se obavam neni stejne. Kdysi jsem si dost hral s jBPM. Je to cista java a fungovalo to docela dobre. Od te doby to preslo pod kridla JBOSSu, dostalo to podporu bpel, vyvijeji k tomu graficky navrhar procesu... V dobe, kdy jsem si s tim hral to bylo spis "knihovna", kterou jste mohl jednoduse pouzit ve sve vlastni aplikaci (coz nejspis zustalo). Urcite stoji za vyzkouseni. Enhydru jsem si take zkusil, ale nemel jsem na ni moc casu... [EMAIL PROTECTED] píše v St 31. 01. 2007 v 07:43 +0100: > Já jsem začal používat Spring Web Flow - > http://www.springframework.org/download. Je k němu pěkně zpracovaná > dokumentace. > > SWF (Spring Web Flow) lze dobře integrovat se Spring Frameworkem > (vyzkoušeno), Struts i JSF. > > Pro SWF existuje i plugin pro Eclipse, který umožňuje vytvření flow v > grafickém prostředí - > http://www.eclipse-plugins.info/eclipse/plugin_details.jsp?id=765 (mě se > jej bohužel nepodařilo rozhodit). > > Dne Tue, 30 Jan 2007 19:04:35 +0100 Martin Chalupa > <[EMAIL PROTECTED]> napsal/-a: > > > Dobrý den, > > > > rád bych se zeptal na Vaše názory a zkušenosti ohledně workflow enginů v > > javě. > > > > Jaký zvolit jazyk pro definování procesu XPDL, BPEL nebo jiný, a podobně. > > > > Procesy, které bych chtěl modelovat, nejsou extrémně složité, kolem 20 > > stavů. > > > > Zatím jsem prozkoumával produkt Enhydra Shark, ale nejsem s ním moc > > spokojen přijde mi příliš komplikovaný. Zajímavé se mi zdálo např. jBPM > > od JBoss. > > > > Předem děkuji za odpověď > > Martin Chalupa > > > > > > > -- S pozdravem - Vladimír Náprstek specialista AKC RWE Energy Customer Services tel: 475 233 102 e-mail: [EMAIL PROTECTED]
RE: eclipse + subversion
Zdravím, > asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta? > Všechno je v něm rychlejší a hromadné přidávání souborů taky zvládne v pohodě > - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková > katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby > je úplně jedno co které IDE podporuje za pluginy. asi mi to uniklo, ale jak jednoduse udelate z commadline vetsi refaktorig, ktery zasahne cca 100 trid movem? Tedy treba split plug-inu nebo naopak presun nejakych trid do spolecne centralni knihovny? Podle mne to znamena jednou zasahovat do kodu a podruhe vypisovat svn mv na vsechny tridy, ktere se presunuly. To bych prave chtel od IDE, abych po refaktoringu mohl jen commitnout a nemusel premyslet nad tim, co se presunulo a kam. Proti command line opravdu nic nemam, a na cruisecontrol serveru si s ni tykam, ale na desktopu ji pouzivam opravdu vyjimecne, protoze i ten checkout delam tak vyjimecne, ze je jednodusi nechat subclipse checkoutnout a naimportovat projekty nez checkoutovat rychle z cmdline a pak rucne doimportovavat projekty z workspace. Pouzivame subclipse cca 2 roky a na zacatku to opravdu katastrofa byla, ale dneska uz ho vubec nevnimame, protoze beha dobre a spolehlive. BTW: Je ta XP metodika, ktera pozaduje aby novy par pracoval na cistem checkoutu tak dulezita? Nestacilo by checkoutovat treba automaticky jednou denne (v noci)? - To nechci delat chytreho, to by me pravdu zajimalo - jestli a jake mate zkusenosti s tim, kdyz par prevezme po predchozim paru jejich workspace... V.
