Kilka spraw jednocześnie, ale inaczej się nie da. Poszukując błędu w jednym z projektów chwilowo porzuciłem lekturę specyfikacji JPA. Powracam do niej od czasu do czasu, ale bez większego zaangażowania, aby wszystkie nowinki spisać. Czuję jednak, że dzisiaj/jutro powrócę do tematu relacji lektury specyfikacji JPA. Tak mi podpowiada zdrowy rozsądek, aby zakończyć JPA i podejść do innych zajęć, ale rozsądek rozsądkiem, a życie przynosi czasami zaskakujące propozycje alternatywne ;-)
I nie inaczej było i tym razem. W moim niewielkim świecie tworzenia oprogramowania jest kilka projektów i technologii, które są na niekończącej się liście do ewaluacji/poznania. Lista ciągle podlega zmianom, w zależności od nastroju i ogólnego klimatu wokół niej.
Jedną z technologii, która od dłuższego czasu mnie nurtuje jest OSGi (http://www.osgi.org). W skrócie, OSGi jest specyfikacją platformy usług nadzorowaną przez OSGi Alliance. Moja dotychczasowa aktywność w tej technologii sprowadzała się do śledzenia poczynań projektów Apache Felix oraz Eclipse Equinox, które są dwoma głównymi projektami otwartymi realizującymi specyfikację OSGi R4 (do pełnej oferty należy dodać jeszcze projekt Knoplerfish). Trwa to już jakiś czas i do tej pory wystarczyło, aby upewnić się, że jest to technologia, którą należy konieczne rozpoznać. W końcu nadszedł ten dzień, a wszystko za sprawą artykułu na JavaLobby - Getting started with OSGi: Your first bundle. Nie mogłem wymarzyć sobie lepszego artykułu do rozpoczęcia poznawania specyfikacji OSGi! Jest niezwykle krótki, acz treściwy i każdemu nowicjuszowi OSGi go polecam na rozgrzewkę. Wychodzę z założenia, że czym więcej osób interesuje się danym tematem tym większa szansa na jego dokładniejsze zbadanie (najczęściej poprzez wymianę doświadczeń) i dla zainteresowania dodam, że OSGi jest platformą dla produktów Eclipse IDE oraz IBM WebSphere Application Server 6.1, a ostatnio zainteresowali się tym również programiści Spring Framework ustanawiając projekt Spring-OSGi. Wciąż to powtarzam, ale będzie to inauguracja w Notatniku - jeśli rok 2006 był rokiem projektów opartych o Spring Framework i Hibernate, a 2007 będzie rokiem powrotu do platformy Java EE 5, to rok 2008 będzie z pewnością rokiem projektów OSGi. Jest to kolejne uproszczenie przy tworzeniu rozwiązań modularnych, a specyfikacje JSR 277: Java Module System oraz JSR 291: Dynamic Component Support for Java SE są kolejnym dowodem, że istnieje duże zapotrzebowanie na takie rozwiązania.
Poza OSGi, na uwagę zasługuje pojawienie się kolejnych wersji projektów codziennego użytku - Eclipse IDE 3.3 M5 oraz Apache Maven 2.0.5. Szczególnie Maven2 był wielce oczekiwany i coraz częstsze błędy pojawiające się w obszarze zarządzania zależnościami powodowały u wielu zwątpienie, czy jest to wystarczająco dojrzałe rozwiązanie do obsługi rozbudowanych projektów, jak np. Apache Geronimo. Eclipse IDE nie imponuje swoim rozmachem w tej wersji, ale pojawiło się kolejnych kilka dodatków, jak formatowanie kodu przy zapisie per projekt, które warte są zainteresowania.
I na koniec, zajmujący mnie ostatnio projekt - JBoss Seam, czyli temat kolejnego spotkania Warszawa JUG w nadchodzący wtorek. Muszę przyznać, że warto było zapoznać się najpierw ze specyfikacjami EJB3 (w tym i JPA 1.0) oraz JSF 1.2, przed przystąpieniem do Seama. Znacznie upraszcza to zrozumienie zaproponowanych w nim rozwiązań. Dodać do tego należy możliwość skorzystania z facelets, ICEFaces, TestNG, Trinidad, ajax4jsf i mamy ciekawą mieszankę projektów w jednym. Na pewno nie można się z nim nudzić. Istnieje możliwość uruchomienia Seama na JBoss AS 4 oraz GlassFish, a w ramach dokształcenia postanowiłem spróbować uruchomienia na Apache Geronimo. Niestety pierwsza próba zakończyła się niepowodzeniem - brak wsparcia dla klienta aplikacyjnego Java EE w Geronimo. Zgłosiłem błąd (GERONIMO-2827) i postanowiłem przyjrzeć się bliżej tematowi. Z pewnością nie uda mi się go poprawić do spotkania, ale może zaraz po nim?! A skoro wróciłem do tematu spotkania, to zastanawiam się, co z tak rozległego projektu jakim jest JBoss Seam należałoby zaprezentować w 1,5 godziny?! Wydaje się, że na jednym spotkaniu o Seamie się nie skończy.
Brak komentarzy:
Prześlij komentarz