Java

Už nějakou dobu pošilhávám po dovednostech maven plugin pro eclipse. Bohužel oficiální plugin pro emacs existuje pouze pro maven verze 1 a pro maven verze 2 existuje jenom plagin s velmi základní funkčností.

Takže sem se rozhodl alespon nějakými patchi přispět do mlýna a doufám, že se tak zvýší šance na zařazení tohoto plagin do oficiální repozitorie.

Nejpve jsem chtěl pouze doplnit vygenerované soubory prj.el o vazbu na hlavní prj.el, ale když sem tak prohlížel co a jak ten plagin dělá a čím se liší od eclipse plaginu, dodělal sem několi dalších fitchurek.

Je to fakt drobnost, jenom pro ty kdož se s lispem moc nekamardi. Kompilace s testem je pak navázána na klávesu F6.

(defun benzin-jde-compile-test nil
  "Do a standard maven build. Consider using the console ... :)"
  (interactive)
   (and (jde-compile) (jde-junit-run)))

(global-set-key [(f6)] 'benzin-jde-compile-test)

Původní jde-maven.el skript havaruje na problému s CDPATH. Můj opravený skript který jsem publikoval dříve zase trpěl problémem se změnou adresáře u otevřených souborů. Dnes přináším ještě jednu opravenou verzi, která již netrpí ani jedním z problémů. /---code (defun benzin-jde-maven2-build (&optional project-file goal args)

Tady jsou krátké skriptáky pomocí kterých můžete Emacs dotunit, aby před uložením souboru změnil všechny tabelátory za mezery. Formátování souboru zůstane nezměneno, jenom tabelátory jsou nahrazeny příslušným počtem mezer. /---code lisp (setq auto-untabify-alist '(( . t) („\\.rb$“ . t) („\\.java“ . t) („\\.xml“ . t) („\\.css“ . t)

Už více než měsíc se snažím u jednoho zaměstnance na počítači rozběhnout připojení k databázi Firebird pomocí JDBC. Mám kvůli tomu spoustu přezčasů, ale nic nepomohlo. Kompletně jsem reinstaloval systém a ani to nepomohlo. JDBC pořád jenom háže hlášku:

org.firebirdsql­.jdbc.FBSQLEx­ception: Could not obtain connection during blocking timeout (5000 ms) org.firebirdsql­.gds.GDSExcep­tion: Unable to complete network request to

Přešel jsem z XEmacsu, ktery se již nějakou dobu jeví jako téměř mrtvý na zbrusu nový Emacs verze 22 (v Gentoo třeba odmaskovat). Všechno jsem bez větších problémů rozjel, jenom kompilace skrz maven se zasekla na chybě spojené s CDPATH.

Po prozkoumání jde-maven.el jsem vytvořil tři funkce, které kompilaci spustí úspěšně. Rozdíl je v tom, že zatímco původní skript nastavoval aktuální adresář jako součást kompilace, můj skript nastaví nejprve aktuální adresář a následně spustí kompilaci. Není to sice tak výhodné, ale funguje to.

Jistě jste již řeěili takovou drobnost, jako jak předat servletu jednoduchý parameter. Například číslo stránky v diskusi, nebo identifikátor editovaného záznamu. Nejspíš jste tento vyřešili pomocí parameterů předávaných metodou GET. Takže jít na další stránku v diskusi jste zapsali jako odkaz na diskuse.html?pa­ge=2. Jedná se o standardní (standardně tohle slovo nepoužívám, protože se mi standardně plete se standartou.) řešení.

Programuju v jazyce JAVA a jako vyvojove prostredi (IDE) pouzivam Emacs resp. XEmacs. Ke zprave projektu (build, deploy, dokumentace atp.) jsem pouzival drive Ant, ale pred nekolika mesici jsem prevedl vsechny sve projektu na Maven2. Jedina a posledni bolistka, ktera oproti Antu zustavala byla horsi podpora prave v Emacsu. Z toho daleko nejvice mne stave absence rychle navigace v chybach.vzniklych pri kompilaci.

Dnes jsem narazil na problém s testováním. Mám interface IDAO, které implementují všechny objekty sloužící jako DAO. Proto logicky vyvstal požadavek na vytvoření abstraktní třídy která implementuje DAO právě pro užití v testech jako mock objekty. Jen mně překvapilo, že jsem to nepotřeboval dřív.

Jenže problém nastal při dědění z takovéto třídy v jiném projektu. Maven2 totiž odděluje třídy používané pro testy od tříd (tada nevím jak jinak je nazvat). Takže jak teda použí testovací třídy v jiném objektu? Nakonec jsem našel: guide-attached-tests

V podstaě musíte udělat dvě věci. V projektu po kterém požadujete, aby své testové třídy nabízel musíte přidat do buildu přidat plugin maven-jar-plugin a nastavení pro goual asi takhle:

   <build>

Nemám moc rád kontejnery, mají tu nepěknou vlastnost, že nad nimi nemáte úplnou kontrolu. Zavoláte nějakou metodu kontejneru, ona zavolá metodu která je spuštěná v jiném vlákně, ta vyvolá výjimku, celý kontejner lehne a vaše aplikace s ním. V lepším případě, lehne vaše aplikace a kontejner žije dál. S trochou dobrého návrhu, vytáhnete aplikaci znovu do funkčního stavu, ale o tom proč aplikace spadla nemá ani páru.