Kolejny problem jaki wylazł to zapisywanie obiektów w db4o. Początkowo założyłem sobie, że niektórym elementom będę przypisywał lokalizacje (na diagramie interfejs IResourceLink). Okazało się jednak, że pochodne IResource (IFolder, IFile) w Eclipse zawierają sporo informacji, z których zapisaniem był problem (PreferencesStore), a które z punktu widzenia AgaviIDE były zbyteczne. Ilość zapisanych obiektów była przytłaczająca, już po chwili pracy baza projektu miała ponad 1 megabajt. Biorąc pod uwagę to, że jest tam zapisywany model, który zmienia się często i w którym wyszukiwanie powinno być możliwie najszybsze sytuacja taka była nie do przyjęcia. Znowu przekopałem cały kod modelu, tym razem po to by korzystać ze klasy java.io.File. Masakra, koniec końców udało mi się całość uruchomić. Builder działa, obiekty są zapisywane (drugi obrazek). Teraz dorzucić jeszcze wyciąganie informacji z plików php i powinno być ok..

Oto output, którym w tej chwili częstuje builder.

Pomyślcie jak fajnie będzie się edytować routing.. podanie ścieżki, wskazanie akcji i gotowe.. albo konfiguracja walidatorów na podobna do tej z JSF Tools

Czas jakiś temu udało mi się stworzyć pierwszy działający edytor w oparciu o Eclipse.
Kilka informacji co pod spodem:

• SharedHeaderFormEditor - ładny tekstowy nagłówek oraz możliwość dodawania zakładek
• FormPage i FormToolkit - użyte do stworzenia układu, który widać na załączonym obrazku
• JFace Databinding - zapewnia propagowanie zmian z formularza do obiektów
• JAXB 2 - mapowanie plików XML do odpowiednich klas
• JFace - table viewer i parę innych dodatków

Całość ogólnie jest prosta niczym konstrukcja cepa, w działaniu sprawia się dobrze. Jak tylko ogarnę kod postaram się opisać krok po kroku jak można coś podobnego stworzyć na własny użytek.

Splatch wraca do gry i będzie grać wysoko! ;-)

Ogólniki

JAXB ma za zadanie ułatwić pracę z XML poprzez automatyczne dostarczanie obiektów zamiast żmudnego, ręcznego obrabiania plików SAX, DOM czy StAX. Jest to dodatkowa warstwa zbudowana na bazie Java Api for XML Processing
. Druga wersja JAXB jest dołączona do J2SE 1.6.

Spójrzmy teraz na schemat budowy JAXB:

1. Kompilator
   1. Schema - dokument opisujący strukturę dokumentu - może to być XML Schema, DTD jak również Relax NG czy też WSDL.
   2. XML /Java Binding Customization - JAXB daje nam możliwość wpływania na wygenerowany kod poprzez ten właśnie mechanizm, dzięki temu można określić np. metody, które będą tworzyć elementy w przypadku odczytu z dokumentu bądź serializować w przypadku zapisu.
2. Runtime
   1. Portable JAXB-annotated classes - kod, który wygenerowaliśmy przy użyciu kompilatora bądź klasy, do których dodaliśmy adnotacje.
   2. Object Factory - klasa, która tworzy obiektowe reprezentacje naszych elementów XML.
   3. Binding runtime framework implementation - obsługuje proces odczytu danych (unmarshalling) oraz ich zapisu (marshalling), obsługuje również walidację. Element ten do poprawnego działania wymaga elementów wymienionych powyżej - czyli klas z adnotacjami oraz ich "fabryki".

Pierwszy projekt

Pamiętam, że kiedyś chciałem stworzyć prostą aplikację w której mógłbym notować jakie książki mam i komu je wypożyczyłem. Niestety w którymś momencie zabrakło chyba sił i poza definicją struktury dokumentu stworzyłem tyko kilka linii kodu. Nie mniej, po drobnych przeróbkach udało się doprowadzić schemat do porządku. W aplikacji będą występować następujące instancje klas:

1. Books - repozytorium książek, zawiera listę książek
2. Book - definicja książki - atrybuty to title, isbn oraz lista autorów
3. Author - reprezentacja autora - atrybuty firstName, lastName. Dodatkowo opcjonalny jest type wskazujący czy mamy do czynienia z tłumaczem czy też z "normalnym" autorem.
4. AuthorType - typ wyliczeniowy - dostępne wartości to Translator, Author

Aby korzystało się nam z kompilatora (xjc) wygodniej podepniemy go pod Eclipse jako narzędzie zewnętrzne. Tu przyda się kilka informacji na temat samego kompilatora:
xjc [-options ...] file/URL/dir ... [-b bindinfo] ...
Gdzie najważniejsze opcje to:

1. -d, katalog do którego trafi wygenerowany kod
2. -b, dodatkowe mappingi umożliwiające zmianę zachowania kompilatora
3. -p, paczka do której trafi wygenerowany kod
4. -classpath, miejsca w których xjc ma szukać klas, które zostały użyte w mappingach

Przykładowo

xjc -d generated schema.xsd

Spowoduje, że klasy wylądują w katalogu generated. Nazwa paczki zostanie zaczerpnięta z atrybutu targetNamespace dokumentu zawartego w schemacie. Obok znajduje się screen z konfiguracją - z ważniejszych informacji - Working directory ustawione na ${project_loc} pozwala nam się nawigować po katalogach względem aktualnie zaznaczonego w nawigatorze projektu. wartość w polu Arguments -d generated ${resource_loc} -verbose -extension -npa oznacza, że wygenerowane klasy wylądują w katalogu "generated" (należy stworzyć taki source folder). Zmienna ${resource_loc} pozwala nam użyć aktualnie zaznaczonego pliku w nawigatorze. Dzięki takiej konfiguracji niezależnie od projektu i pliku jesteśmy w stanie wygenerować potrzebne nam klasy poprzez dwa kliknięcia - pierwsze w nawigatorze, drugie na ikonie external tools.

Schemat jest dostępny do ściągnięcia, podobnie jak przykładowy plik z danymi. Proszę zwrócić uwagę na to jak jest zdefiniowany główny element dokumentu - poprzez zawarcie typu anonimowego. Jeśli zdefiniujemy oddzielnie element i typ to wówczas konieczne będzie ręczne dodanie adnotacji @XmlRootElement przy klasie Books. O tym dlaczego JAXB się tak zachowuje można wyczytać na jednym z Sun-owskich blogów.

package pl.dywicki.books.app;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;

import pl.dywicki.books.Author;
import pl.dywicki.books.AuthorType;
import pl.dywicki.books.Book;
import pl.dywicki.books.Books;
import pl.dywicki.books.ObjectFactory;

/**
 * Testowa klasa pokazująca użycie JAXB do zapisywania danych.
 *
 * @author Łukasz Dywicki
 */
public class App {

	public static void main(String[] args) throws Exception {

		// repozytorium książek
		Books books = new Books();

		// przykładowa książka
		Book book = new Book();
		book.setTitle("Test title");
		book.setIsbn("111-111-111");

		// testowy autor
		Author author = new Author();
		author.setFirstName("Martin");
		author.setLastName("Fowler");
		book.getAuthor().add(author);

		// testowy tłumacz
		author = new Author();
		author.setFirstName("Łukasz");
		author.setLastName("Dywicki");
		author.setType(AuthorType.TRANSLATOR);
		book.getAuthor().add(author);

		// dodanie książki do repozytorium
		books.getBook().add(book);

		JAXBContext context = JAXBContext.newInstance(ObjectFactory.class);
		Marshaller marshaller = context.createMarshaller();
		// chcemy ładnych wcięć w wyniku! :)
		marshaller.setProperty("jaxb.formatted.output", true);
		marshaller.marshal(books, System.out);
	}

}

Po uruchomieniu tego przykładu w konsoli powinien pokazać się taki oto wynik:

< ?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2_books xmlns:ns2="http://dywicki.pl/books">
    <book>
        <title>Test title</title>
        <isbn>111-111-111</isbn>
        <author>
            <firstname>Martin</firstname>
            <lastname>Fowler</lastname>
        </author>
        <author>
            <firstname>Łukasz</firstname>
            <lastname>Dywicki</lastname>
            <type>Translator</type>
        </author>
    </book>
</ns2_books>

(Zamiast ns2_books powinno być ns2:books, ale narzędzie kolorujące składnie sobie nie radzi).

Dla zainteresowanych załączam źródła projektu.

Wiadomo, że ten release wyjdzie, podobnie jak Europa, 29 czerwca. Pojawiły się pierwsze zmiany, które wejdą w skład nowej dystrybucji. Na tą chwilę jeszcze nie wiadomo ile projektów będzie obejmować Ganimedes, póki co jest ich kilka, miejmy nadzieję, że przynajmniej tyle co Europa!

Pierwszym krokiem jest podpięcie własnych plików z definicjami struktur do Eclipse. Wskakujemy zatem do Window > Preferences a następnie do Web and XML > XML Catalog. Mamy tam listę definicji, których używa WST do podpowiadania składni. Jest miejsce na definicje użytkownika - zatem dorzucamy nowy wpis do obsługi autoload. Po pierwsze wybieramy nowy element. Do wyboru mamy dwa rodzaje źródeł - plik ze wskazanego projektu bądź z określonej lokalizacji. Drugi ma tą przewagę, że nie ma problemów z jego przenoszeniem pomiędzy różnymi workspace'ami. Po wskazaniu źródła z poprawnym dokumentem xsd bądź dtd Eclipse samo wypełni pola. Jedyne co pozostaje nam zrobić to kliknąć i potwierdzić.

Po tym zabiegu możemy zabrać się za edytowanie istniejących plików bądź stworzyć nowy w oparciu o kreator.. Aby to zrobić korzystamy z opcji File > New > Other z listy wybieramy XML i tworzymy na podstawie schematu. Po wybraniu tej opcji mamy dostępną listę schematów, na podstawie których WST jest w stanie wygenerować szablon dokumentu.

Koniec końców mamy w pełni funkcjonalne podpowiadanie składni w dokumencie XML. W podpowiedziach jest również dodawana informacja o krotności elementów * (zero i więcej), + (jeden i więcej), ? (zero lub jeden) a także wyświetlana dokumentacja. Gdy pracuje się z dobrze opisanym schematem - np plikiem xsd, w którym autorzy nie żałowali miejsca na adnotacje z informacjami na temat poszczególnych elementów - nie ma nawet konieczności skakania po oknach w celu doczytania informacji - jakiego atrybutu bądź znacznika użyć - po prostu mamy to od razu w edytorze. Bez jakiegokolwiek wysiłku, kilkoma kliknięciami zyskujemy funkcjonalne narzędzie. :)

Druga opcja, która jest dostępna w większości edytorów tekstowych to zdefiniowane szablony. W celu zdefiniowania nowego szablonu w preferencjach otwieramy zakładkę Web and XML > XML Files > Templates. Znajdziemy tam listę z możliwością modyfikacji. Opcję tą odkryłem przy okazji walczenia z pisaniem schema.xml dla Propela z ręki. Była niezastąpiona i zastępowała sporo pracy związanej z tępym kopiowaniem tekstu. W definicji szablonów mamy do dyspozycji kilka pre definiowanych zmiennych, są one przydatne podczas tworzenia szablonów nowych plików. Możemy również deklarować własne zmienne - ${nazwa_zmiennej}. Po wstawieniu szablonu do pliku możemy się nawigować po miejscach wystąpień zmiennych przy użyciu tabulatora. Miejsca, w których powtarzają się te same nazwy zmiennych są automatycznie uzupełniane, tak, że wpisując przy pierwszej zmiennej ${name} nie musimy powtarzać tej czynności w drugim miejscu.

Mam nadzieję, że przyda się w praktyce! Przy okazji pragnę Was, drodzy czytelnicy, poprosić o opinie na temat lightboxa, czy nie przeszkadza Wam jego użycie, być może wolicie tradycyjne linki do plików? Pomijam efekty graficzne, bo wygaszanie tła etc przy trzecim razie bardziej irytuje niż cieszy oko. Jak sądzicie - usunąć lightboxa? Momentami mam też problemy z rozmieszczaniem "obrazków" stąd są prozżucane po akapitach raz z lewej raz z prawej ponieważ przy mniejszych rozdzielczościach zachodzą na siebie, co powoduje niezbyt miłe efekty.

Zastanawiałem się kiedyś skąd twórcy Eclipse biorą nazwy dla kolejnych wydań. O ile samo Callisto ma wiele znaczeń (mitologiczna kochanka Zeusa, postać filmowa, księżyc Jowisza, komiks, model samochodu czy też kapela) o tyle w parze z Europą, najnowszym wydaniem kwestia staje się jasna. Bez wątpienia chodzi tu o księżyce Jowisza. Troszkę zadziwiający jest fakt, że dobór nazw nie zbiega się z kolejnością księżyców (największy jest Ganimedes, następnie Callisto, Io i na samym końcu Europa). No, może dywagacje na temat nazw i pochodzenia pozostawimy, chociaż "astronomiczny" akcent Eclipse nas na długo nie opuści, bowiem w notce tej zamierzam przedstawić wcześniej wymienione, najświeższe, wydanie - Europę.

Historia wydań

Były czasy, kiedy skompletowanie sobie wszystkich potrzebnych pluginów do Eclipse wymagało wiele wysiłku. A to stąd pobrać GMF, stąd JET, do tamtego jeszcze coś i tak przez pół dnia. Każdy projekt miał własny update site, który zawierał mniej czy też bardziej stabilne wersje. Wykorzystanie funkcjonalności "select required" ograniczało się tylko i wyłącznie do tego, że po kliknięciu w przycisk po prostu klęliśmy, że nie działa i trzeba szukać kolejnego update site'a. Problem ten definitywnie rozwiązało Callisto. Na jego podstawie zostały zasadniczo stworzone trzy "dystrybucje". Pierwsza dla programistów J2SE, druga dla osób zajmujących się Eclipse od podszewki oraz trzecia dla programistów C/C++. Dodatkowo korzystając z istniejących pakietów można przy użyciu update managera stworzyć pakiet dostosowany do własnych potrzeb.
Europa jak wcześniej wspominałem jest znacznie większa, ponieważ zawiera aż 21 projektów podczas gdy na Callisto składało się ich "tylko" 10. Ponadto nowe wydanie zawiera dodatkową dystrybucję przeznaczoną do pracy z JEE. Myślę, że wielkość tego wydania jest znakomitym dowodem popularności Eclipse jak i prężności developerów.
Jako ciekawostkę dodam kilka liczb, na które trafiłem dzięki notce na blogu Iana Skerretta
Wartość 16 projektów spośród 21, notowanych na Ohloh.net to, uwaga, 305 991 384 dolarów (słownie trzysta pięć milionów, dziewięćset dziewięćdziesiąt jeden tysięcy, trzysta osiemdziesiąt cztery dolary). Jest to wartość około 19 339 912 linii kodu rozwijanych ostatnimi czasy przez 312 osób!

Dostępne dystrybucje

Java. Dystrybucja przeznaczona do pracy z J2SE. Sercem platformy jest JDT (Java Development Tools), czyli "standardowy" edytor rozbudowany o nowe opcje. Zawiera część WTP (edycja XML, XSD itp).

JEE.Wersja przeznaczona do pracy z JEE jak i "starym" J2EE. Zawiera WTP 2.0 (Web Tools Platform) oraz JST (J2EE Standard Tools) - wsparcie dla edycji JSF, JSP itp. Zapewnia wsparcie dla JPA. Jest to najbardziej "wypasiona" dystrybucja, ponieważ zawiera większość projektów wydanych w ramach Europy.

Classic. Dystrybucja będąca miksem wersji Java i RCP. Zawiera źródła projektów, dokumentację nie tylko dla użytkowników ale i dla developerów. Przeznaczona do tworzenia aplikacji w oparciu o Eclipse RCP jak i rozszerzeń samej platformy.

C/C++. Kompletne środowisko dla programistów piszących w językach C/C++ oparte na Eclipse. Całość okrojona do CDT/CVS/RCP. Brak źródeł jakichkolwiek pluginów, wsparcia dla czegoś niezwiązanego z C/C++. Tylko ta dystrybucja nie jest zintegrowana z Mylynem.

RCP. Pochodna wersji Classic okrojona tylko o ilość źródeł (nie zawiera źródeł JDT, CVS)

Wszystkie wymienione wyżej dystrybucje można oczywiście modyfikować przy pomocy standardowej aktualizacji. Są to tylko pre definiowane wersje, które mają na celu ograniczenie do minimum ilości pracy potrzebnej do skompletowania środowiska. Przy użyciu każdej z tych dystrybucji możemy praktycznie od razu zacząć pracę. Drobnym wyjątkiem jest tutaj C++, ale o tym dalej..

Najciekawsze rozwiązania

Mylyn 2.0

Zdaje się, że Mylyn stał się perełką całej platformy, aż dziw bierze, że tak proste narzędzie powstało "dopiero" teraz. Piszę dopiero, ponieważ rozszerzenie to ma już kilka lat, jednak dopiero niedawno pojawił się "szum medialny" wokół niego. Pierwsze screencasty, prezentacje i w rezultacie gwałtowny wzrost popularności rozszerzenia. Jest to jeden z najwyżej ocenianych i najbardziej aktywnych dodatków do platformy na Eclipse Plugins Central.

Czym jest Mylyn? Mylyn to narzędzie integrujące Eclipse z repozytoriami zadań takimi jak JIRA, Trac, Bugzilla i tak dalej. Dane, które pobierze z repozytorium zapisuje lokalnie i co jakiś czas synchronizuje. W ten sposób w Eclipse możemy przeglądać i monitorować przebieg prac nad danym zadaniem. Co więcej, jeśli do zadania dołączymy kontekst (załącznik). W odpowiedniej perspektywie możemy przeglądać listę zadań (zapytań). Na liście tej są oznaczone zadania, które są zakończone, otwarte, aktywne czy też jeszcze nie przeczytane.

Mylyna można stosunkowo łatwo rozszerzać. Coraz więcej dostawców integruje swoje narzędzia z Mylynem dzieki czemu kontekst może obejmować nie tylko Package explolera ale również widoki tj outline itp. Sam nawet próbowałem troszkę powalczyć z tym rozszerzaniem, niestety z racji na to, że zdecydowałem się na próbę Mylyn-PDT poległem. Przykładowe implementacje są bardzo proste. Patrząc na klasy dostarczone razem z Mylynem modyfikujące zawartość różnych widoków można stwierdzić, że to w sumie nie jest trudne. No, ale w praktyce bywa inaczej.
O ile braki w komentarzach tego pierwszego można uzupełnić odwiedzając wiki o tyle z PDT tak łatwo już nie jest. Wszędzie jakieś braki w komentarzach, trafiają się fragmenty, gdzie jest publiczny interfejs a nie ma w nim nawet linijki komentarzy. Wydaje mi się, że takie sytuacje raczej nie sprzyjają PDT Summer Camp. No, ale do PDT 1.0 mamy jeszcze troszkę czasu, więc być może coś w tym projekcie się poprawi....

Na koniec dodam jeszcze dwa screenshoty pokazujące, jak głęboko Mylyn jest zintegrowany z edytorem tekstu. Może on "zawijać" te fragmenty kodu, które nie mają nic wspólnego z zadaniem pozostawiając tylko te, które są zawarte w kontekście. Świetna sprawa, gdy ma się klasy, które mają kilkaset linii kodu i odnalezienie w nich metody to wyłapywanie nazwy w outline. ;)

Mylyn bez wątpienia jest rozszerzeniem godnym uwagi. Jeśli w pracy macie do czynienia ze sporym stosem kodu w którym często na zmianę łatacie różne błędy to bardzo ułatwi on Wam życie. Wydaje mi się, że na tą chwilę żadne środowisko nie posiada tak dobrej integracji z repozytoriami zadań.
Osobiście jest to dla mnie najlepsza rzecz jaka weszła do Europy.

Eclipse RCP 3.3/JFace

. W nowej wersji jest kilka usprawnień. Najbardziej istotnym jest nowy sposób na zarządzanie widoków. Wcześniej widoki mogły wysuwać się tylko z jednej strony. Nie było czegoś takiego jak "fast view" na modłę Visual Studio, gdzie zakładki chowały się bądź pokazywały gdy najeżdżało się na nie myszą. Połowicznym sposobem na ten problem była minimalizacja/maksymalizacja widoku.
Połowicznym, ponieważ pokazanie konsoli powodowało ponowne pokazanie wszystkich widoków. Od wersji 3.3 możemy wybierać który widok ma się pokazać dynamicznie, minimalizować całe "grupy" widoków. Jak dla mnie bomba, dzięki temu mogę napisać sobie na szybko coś w edytorze mając widoczny tylko outline i dynamicznie wysuwaną konsolę, bez niepotrzebnych mi widoków. Dodam, że widoki zachowują się tak samo w RCP jak również IDE. Dodając do tego również Eclipse Packaging Project [nie jest częścią Europy] w połączeniu z PDE zyskujemy środowisko do tworzenia aplikacji okienkowych od A (kodowanie) do Z (tworzenie instalatorów).

JDT 3.3

Wraz z ewolucją platformy postępuje ewolucja JDT, które jest pokazem możliwości Eclipse. Wiele osób kojarzy JDT z Eclipse, chociaż tak nie jest JDT to tylko przykładowa (chociaż bardzo dobra) implementacja środowiska w oparciu o Eclipse. Nowa wersja dodaje kilka usprawnień.
1. Save actions. W chwili gdy zapisujemy edytowany plik JDT może wykonać różne operacje. Od usunięcia zbędnych importów i dodania adnotacji @Override/@Deprecated tam gdzie trzeba przez posortowanie pól, metod bo nazwach oraz formatowanie kodu po rzecz tak błahą jak usunięcie zbędnych spacji z końca linii. Nigdy więcej wciskania Ctrl+Shift+O, Ctrl+Shift+F, zrobi to za Ciebie edytor! Sam powoli zaczynam walczyć ze sobą by nie wciskać pierwszego z tych skrótów przed zapisaniem pliku.
2. Spelling. Sprawdzanie pisowni w edytorze? Czemu nie, w końcu komentarze powinny być pisane językiem zrozumiałym dla wszystkich, nie tylko dla autora. ;) Opcja ta pozwoli wyłapać literówki, nie sprawdzi jednak czy zdanie jest poprawne pod kontem składni czy gramatyki. Tak czy owak lepiej poprawić błąd w komentarzu zanim kod się wrzuci do repozytorium niż po fakcie, gdy ktoś zwróci nam uwagę. Błędy składni JDT podkreśla miłym dla oka żółtym kolorem. Niestety nie udało mi się poprawnie skonfigurować słownika dla języka polskiego. Wersja z Open Office/kurnik.pl jest zapisana w troszkę innym formacie niż wymaga plugin, co powoduje problemy.
3. Zmienione zachowanie skrótu CTRL+F11. Domyślnie skrót ten uruchamia ostatnią konfigurację dla aktywnego pliku. Prawdę powiedziawszy doprowadzało mnie to do szewskiej pasji i zmieniłem to na standardowe zachowanie tak by działało tak jak wcześniej, czyli ostatnia uruchomiona konfiguracja.
4. Podpowiadanie w blokach catch. Standardowo trzeba było tam wpisywać z "palca" nazwę wyjątku posiłkując się inspectorem. W wersji 3.3 do wyboru mamy tylko te wyjątki, które wylecą z danego bloku.

Drobnych zmian jest więcej, nie mniej ich opis pomijam z racji na to, że nie ma to być changelog a tylko informacja o tym, co się stało. Tak więc z mniej istotnych - skrót do nawigacji po widokach (CTRL+F3) bądź usprawnione podpowiadanie w edytorach PDE bądź "rename in line", czyli bezpośredni podgląd zmian nazwy elementu bez konieczności uruchamiania kreatora.

Web Tools 2.0

Projekt ten obejmuje wiele subprojektów, których ilość jest dość spora. Web Standard Tools to nic innego jak komplet edytorów do edycji plików xml, xsd, html, css, js, wsdl i tak dalej. Zmian w stosunku do poprzednich wersji nie odnotowałem [czyt. nie zauważyłem].
Screenshoty z wersji 1.5: XML 1, XML 2, XSD 1, XSD 2, XSD 3.

J2EE Standard Tools

Jednym słowem: kobyła. Jeśli jest coś w J2EE/JEE czego nie można edytować przy użyciu tego narzędzia to musi to być chyba jakaś spora nowość. ;) Na uwagę zasługuje poprawiony edytor graficzny, który sprawuje się całkiem dobrze nawet przy nie do końca poprawnej strukturze pliku. Potrafi on sobie poradzić [czyt. ominąć] skryplety i bardzo ładnie zaznacza elementy zawarte w tagach jsp - niezależnie od tego czy jest to logic:empty (struts) czy też c:if (jstl). Edytor graficzny jest połączony z edytorem tekstowym. Po kliknięciu na jakiś komponent w edytorze graficznym w edytorze tekstowym zostanie on zaznaczony. Problemem z JST jest niestety jego "ręczna" konfiguracja. Nie ma nigdzie opcji pozwalającej na zmianę katalogu zawierającego pliki przeznaczone do spakowania w WAR. Przy korzystaniu z Mavena trzeba edytować plik konfiguracyjny pluginu!
Oczywiście sam plugin ma bardzo wiele opcji - można przy jego pomocy tworzyć aplikacje w oparciu o EJB2.1/3 a także z użyciem JPA, niestety nie miałem do tej pory okazji do wykorzystania tegoż, stąd rezygnuję z opisu.

CDT 4.0

Nie jestem programistą C/C++ i gdyby nie studia to prawdopodobnie uniknąłbym konieczności poznawania CDT. No, ale okazja się nadarzyła, i prawdę powiedziawszy nie mam powodów by żałować. Do C++ jest wiele środowisk. Jest komercyjne (Visual C++) i niekomercyjne (Visual C++ Express Edition) jak i DevCpp. Są zapewne też inne, mniej bądź bardziej popularne. Mi się nie spodobało ani jedno ani drugie, być może z racji na przyzwyczajenie do Eclipse, jakkolwiek samo CDT również ustępuje JDT, chociaż patrząc na DevCpp oferuje (tu piszę bardzo subiektywnie) większą funkcjonalność.
Edytor sprawuje się bardzo dobrze, podpowiada tam gdzie trzeba to co trzeba. Mamy do dyspozycji gro opcji - od formatowania kodu przez dyrektywy kompilatora, dodatkowe biblioteki i tak dalej. Opcji jest multum i ja jako nowicjusz nie miałem okazji by wykorzystać wszystkie.
Bolączką jest niestety brak dorzucania dyrektyw #include tak jak to ma miejsce w przypadku JDT, gdzie wybieramy klasę i import już jest. Trzeba się też przyzwyczaić do tego, że błędy zostaną podkreślone dopiero po próbie kompilacji, ponieważ ta wtyczka bazuje na tym, co zwróci kompilator w czasie pracy, nie ma możliwości weryfikacji kodu just-in-time. Jest za to debugger oparty o gdb. Działa on bardzo dobrze i nie ma problemów z jego użyciem. Nie odbiega on wiele od tego, co ma Java.
Troszkę Brakuje mi czegoś na modłę "quick fix", gdzie wybieramy proponowane rozwiązanie dla danego problemu. Zapewne wynika to w dużej mierze z tego, że C++ jest językiem bardziej złożonym (mniej doskonałym?) niż Java i samo zaimplementowanie mechanizmu propozycji eliminacji błędów byłoby bardzo kłopotliwe. Kto wie, być może w przyszłych wersjach będziemy mogli zobaczyć więcej. Wierzę, że developerzy pracujący nad tym pluginem mają ambicje by tworzyć najlepsze środowisko do C++, które będzie miało funkcjonalność taką samą bądź jeszcze lepszą niż JDT. Samo CDT 4.0 dosyć szybko stanęło w szranki z WTP o pierwsze miejsce pod względem ilości pobrań. Przegrało po kilku dniach walki. Taki stan rzeczy (CDT wciąż jest drugie) może świadczyć o sporym zainteresowaniu takim środowiskiem w społeczności programistów C/C++. Trzymam kciuki za rozwój tego projektu, ponieważ z nim pisanie w C++ stało się dla mnie przyjemnością! :)

Czym ma on być? Ma być ujednoliconym szkieletem umożliwiającym programistom dostęp do baz danych, dokumentów XML jak i zewnętrznych systemów pokroju EAI przy użyciu istniejących technologii tj. Java Persistence API (JPA), Java Architecture for XML Binding (JAXB), Java Connector Architecture (JCA), and Service Data Objects (SDO). Cel ma być uzyskany we współpracy ze specjalistami od OSGi przy pomocy implementacji przykładowych implementacji, które pokażą jak używać wcześniej wymienionych interfejsów. Dzięki oparciu całości na platformie OSGi pomysłodawcy chcą zyskać niebywałą do tej pory w tego typu projektach przenośność i modularność co w połączeniu ma zaowocować mariażami (a może mezaliansami) różnego rodzaju.
Na stronie z propozycją jest prosty schemat, który wstępnie obrazuje architekturę szkieletu:

Warto zwrócić uwagę na to, że całość projektu nie będzie uzależniona od Eclipse jako takiego a jest tylko rozwijana w ramach fundacji eclipse. Całość będzie można używać zarówno z poziomu Javy EE jak i Javy SE (jak domniemywam również Swing).

Głównym pomysłodawcą projektu jest Oracle z którego ramienia będzie póki co pracować najwięcej developerów, głównie tych, którzy wcześniej zajmowali się TopLinkiem. Jakkolwiek w deklaracji pod koniec propozycji pada zdanie czy też zaproszenie - drzwi są otwarte dla chętnych. :)

Osobiście jestem bardzo ciekaw efektów jakie przyniesie ten projekt, ponieważ znacznie by on ułatwił prace nad aplikacjami stricle biznesowymi opartymi na Eclipse RCP z racji na to, że wystarczy podpiąć się do dostarczonych usług OSGi by móc korzystać z bazy danych czy też wyciągać dane z jakiegoś podsystemu. Fajnie by było uprościć walki, powiedzmy z Hibernate i jego używaniem pod RCP.
Dodam, że Eclipse Persistence Services to kolejny "dość egzotyczny" projekt realizowany w ramach fundacji nie związany ściśle z platformą Eclipse - wystarczy wspomnieć Eclipse Communication Framework z inkubatora, który w wersji 1.0 wchodzi już w skład najbliższego zbiorczego wydania - Europy

• AspectJ Development Tools (AJDT) 1.5
• C/C++ Development Tools (CDT) 4.0
• Dynamic Languages Toolkit (DLTK) 1.0
• Eclipse Communication Framework (ECF) 1.0
• Eclipse Modeling Framework (EMF) 2.3
• Graphical Editing Framework (GEF) 3.3
• Graphical Modeling Framework (GMF) 2.2
• Mylar 2.0
• Web Tools Platform (WTP) 2.0

Zbiorcze wydania takie jak Europa czy Eclipse ułatwiają pracę wszystkim. Począwszy od developerów pluginów kończąc na użytkownikach walczących z zależnościami pomiędzy nimi (skąd ja im wytrzasnę EMF 2.2.1.234?!). Europa ma określone wymogi, które projekty muszą spełniać oraz wymogi, które projekty powinny spełniać. Całe zamieszanie jest ściśle kontrolowane poprzez określone daty poszczególnych kroków (od release'ów M5 po RC4), a wszystko skończy się 29 czerwca.
Odliczanie się rozpoczęło jakiś czas temu, między innymi na blogu Denisa Roy'a. We wspomnianej nocie pisze, że ilość commitów do repozytoriów oraz ruch na Bugzilli może świadczyć tylko o tym, że nadchodzi release, lub co gorsza 20 releas'ów. Ruch jest ogromny, wg Denisa strona obsługuje setki tysięcy pobrań największych projektów, rozwijanych w ramach platformy, takich jak CDT, WTP czy samego Eclipse'a.
Teraz już wiem, dlaczego strony i repozytoria Eclipse'a obsługuje ponad 50 serwerów i że nie jest to bujda. :)

Czy Europa odniesie sukces? Prognozuję, że tak, i że będzie to sukces wielki, gdzieś dwa razy większy niż w przypadku Callisto a my przez najbliższe kilka miesięcy będziemy mieli zapewniony dostęp do świeżych i stabilnych wersji pluginów i solidną podstawę do budowania własnych!