Social coding

Tytuł jest trochę naciągany, ale w pewien sposób oddaję to co opiszę poniżej.

Lubię przeglądać cudzy kod ;). Tak bez szczególnego celu. Może to być w formie śledzenia (podczas synchronizowania się) tego co zostało wkomitowane przez kolegów w pracy; czy przeglądania kodu projektów dostępnych w sieci. Często można zaleźć coś ciekawego, co zmusi do zastanowienia i w rezultacie pozwoli na odkrycie ciekawej biblioteki czy konstrukcji w kodzie.

Szczególnym przypadkiem jest przeglądanie plików pom.xml, wymaganych przez mavena. Zawiera się tu techniczny (ogólny) opis danego projektu: to jakie bibliotek czy pluginy zostały w nim użyte. Można zobaczyć co jest stosowane w podobnych przypadkach, z jakimi się stykamy, i dzięki temu odkryć coś użytecznego, np. wspominane już biblioteki.

I tutaj rodzi mi się pomysł na udział społeczności. Fajnie byłoby mieć narzędzia, które na podstawie pom, mojego aktualnego projektu, przeszuka sieci pod kątem innych pomów dostępnych gdzieś tam. Wynikiem tego przeszukania mógłby być wykaz potencjalnych bibliotek, którymi mógłbym być zainteresowany. Coś w stylu tego co ma np. amazon: propozycji książek którymi mógłbym być zainteresowany. Tutaj brzmiałby to tak: użytkownicy biblioteki X i Y stosowali także bibliotek Z – może warto się nią zainteresować.

Pliki pom są tworzone w ustalonym formacie dlatego też napisanie parsera który przeszedłby po wszystkim co znajdzie i zebrał statystyki nie powinno być trudne. Tak samo osoby dostarczające swoje pom_y (przyjmując że jest to jakiś serwis dostępny globalnie), jako kryterium zapytania, powodowałyby że poziom dostępnych statystyk rósł by.
Statystyki taki naturalnie nie dostarczą precyzyjnej wiedzy, ale pomogą rzucić światło na panujący trend.

Działania takiego narzędzia wyznaczają nawyki użytkowników. W moim przypadku jest to przeglądanie pom_ów i na podstawie tego decydowanie jaką bibliotek poznać bliżej. Mogą być inne zachowania związane z przeglądaniem kodu, które można sformalizować i spróbować zatrudnić do tego komputer. Na pewno nie otrzymamy tu wyczerpującego sprawozdania, ale coś co pozwali nam ułatwić choć trochę życie ;).

Podejście do mavena

Maven w połączeniu z m2eclipse jest o wiele przystępniejszy ;).
Jeśli pracuje się w eclipse, to taki zestaw oferuje wygodny sposób na sprawdzanie różnych koncepcji czy bibliotek, a to poprzez zarządzanie zależnościami. Zarządzanie jako takie oferuje san maven, ale plugin (m2eclipse) sprawia że jest to wygodniejsze (prywatne odczucie :)). Ma się także dzięki temu dostęp do ładnego edytora pomów, jednak treścią tego wpisu będzie to, że taki zestaw daje większą kontrole nad procesem budowy realizowanym przez maven.

Tak więc maven to wspaniałe narzędzie, pozwalające na szybkie wystartowanie z pracą. Wszytko pięknie jak postępuje się zgodnie z ustaleniami. W chwili kiedy sypnie błędem; albo nie, ale nie robi tego co się oczekiwało, mogą zaczynać się schody (znowu prywatne odczucie :)). Jest w tym chyba także trochę winy szybkości z jaką można tworzyć nowe projekty czy dodawać rozszerzenia. Ponieważ kiedy potrzebne jest aby pakować wynikową aplikacje do wara to odszukuje się w sieci odpowiedni wycinek skryptu (jakiegoś pluginu) i już jest war; trzeba wygenerować jakieś klasy, to kopiowany jest następny wycinek i generowanie działa. I bardzo często (mi się tak zdarzało) pracując w taki sposób robi się to bez dokładniejszego wczytania się w dokumentacje danego plugina (jeśli jest na przyzwoitym poziomie) i zadowala się tym, że teraz wydaje się że działa tak jak chcemy. Później natomiast okazuje się że przestaje działać (np. w połączeniu z innymi pluginami) i trzeba szukać dlaczego.
Tak więc mamy na początku zachętę w postaci szybkiego efektu, ale jeśli chce się coś więcej to późniejsza nauka narzędzia (plugin_a) nas nie o minie ;).
Przerywając te wywody skupie się na konkretnym przypadku i przedstawieniu w nim jak można się zabrać za maven_a (jego pluginy), kiedy coś do końca nie działa.

Stworzenie problemu
Istniała potrzeba generowania dwóch jarów (część kliencka i serwerowa), użyty plugin to maven-ejb-plugin. Pierwsza wersja (skopiowana/sklejona radośnie z znalezionych przykładów) to:

	 
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-ejb-plugin</artifactId>
	<configuration>
		<generateClient>true</generateClient>
		<ejbVersion>3.0</ejbVersion>
		<clientIncludes>
			<clientInclude>com/test/client/**</clientInclude>
		</clientIncludes>
	</configuration>
</plugin>

i działa, pojawia się drugi jar kliencki z klasami ze wskazanych pakietów. No i hula to jakiś czas, aż przychodzi prośba aby jar serwerowy miał też wyselekcjonowane klasy (nie zawierał części klienckiej). Nie ma problemu, w dokumentacji pisze, że tak można, więc wpis wygląda teraz tak:

	 
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-ejb-plugin</artifactId>
	<configuration>
		<generateClient>true</generateClient>
		<ejbVersion>3.0</ejbVersion>
		<clientIncludes>
			<clientInclude>com/test/client/**</clientInclude>
		</clientIncludes>
		<excludes>
		  <exclude>com/test/client/**</exclude>
		</excludes>
	</configuration>
</plugin>

Uruchamia się proces budowy i nie widać efektu, jar serwera ciągle zawiera klasy ze wszystkich pakietów. Wykonało się dla pewności clean_a, ale ewidentnie widać, że nie robi tego co miało i nie skarży się też żadnymi wyjątkami.
Tutaj powinienem spokojnie przeczytać dokumentacje i zrobić dokładnie jak tam jest, ale nastąpił pewien etap blokady i nie widziałem dość oczywistego błędu który popełniałem.
Zamiast tego zacząłem szukać rozwiązania na około.

Dochodzenie do rozwiązania problemu
Jako że ewidentnie plugin nie robił co twierdziła dokumentacja, a że był napisany w javie to postanowiłem dobrać się do jego źródeł. Najpierw poprzez dodanie odpowiedniej zależności:

	 
		<dependency>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-ejb-plugin</artifactId>
			<version>2.2.1</version>
		</dependency>

sprawiłem że jar plugina był w moim projekcie. Potem wykorzystując możliwości jakie dawał m2eclipse pobrałem źródła i mogłem przejrzeć w miarę prosty kod pluginu(dwie klasy z czego jedna to help). Okazała się że jest tam obsługa owego parametru, który powoduje odfiltrowanie klas z części serwerowej. W takim razie jedno zostało wyjaśnione, to że dokumentacja zgodna jest z kodem. Wykorzystałem więc następną możliwość jaką dawał mi plugin do eclipsa i odpaliłem cały proces budowy maven w trybie debug stawiając pułapki wewnątrz kodu podejrzanego plugina (było trochę zabawy, aby to zrobić, ale da się zmusić eclipsa do tego). W ten sposób zobaczyłem że moje pułapki w (wykonywany) kodzie zupełnie rozjeżdża się z tym co prezentowane jest w podglądzie kodu, tak jakbym patrzył na zupełnie inny kod. Co wskazało na błąd, który tu popełniałem. Budowałem na starszej wersji, która nie obsługiwała tego co chciałem zrobić. To że nie wskazałem wersji definiując plugin (co dziwne zrobiłem to kiedy chciałem podciągając źródła) sprawiło że w tym wypadku maven podciągną wersje starszą (ciekawa jak jest polityka wybierania wersji?). Tak więc wpis uległ zmianie:

	 
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-ejb-plugin</artifactId>
	<version>2.2.1</version>
	<configuration>
		<generateClient>true</generateClient>
		<ejbVersion>3.0</ejbVersion>
		<clientIncludes>
			<clientInclude>com/test/client/**</clientInclude>
		</clientIncludes>
		<excludes>
		  <exclude>com/test/client/**</exclude>
		</excludes>
	</configuration>
</plugin>

i działa tak jak trzeba (do następnych problemów).

Wnioski
Nauczka na przyszłość to pamiętać, w którym miejscu można popełniać błędy w mavenie:

• poprzez niedokładne czytanie dokumentacji i pośpiech w realizacji (to akurat jest bardziej ogólne ;));
• nie wskazywanie wersji pluginu może dużo namieszać.

A co do tego jak poszukiwać rozwiązania to dużą zaletą jest możliwość:

• szybkiego podglądu kodu pluginu;
• a jeśli to nie pomaga to prześledzenie jego pracy.