Po Democampie

Jak pewnie wiecie w zeszły weekend wybrałem się na Democamp do Poznania. Początkowo planowałem wybrać się na całe dwa dni, ale doszedłem do wniosku, że najciekawsze dla mnie rzeczy będą w niedzielę. Chciałem się dokładnie dowiedzieć jaka jest formuła tego wydarzenia, a dokładniej chodziło mi o poznanie formy prezentacji poszczególnych startupów.

W tym roku obsada jury była międzynarodowa. W gronie oceniających pojawili się przedstawiciele firm typu Venture Capitals pragnących ewentualnie zainwestować w jakiś dobrze rokujący projekt.
Prezentacje startupów odbywały się w języku angielskim. Trwały one po 7 minut. Następnie jury zadawało pytania związane z planem biznesowym, aktualną dochodowością projektu i planach jego rozwoju. Możliwość zadawania pytań mieli również widzowie. Odbywało się to za pomocą Flakera. Powinienem również wspomnieć, że festiwal startupów ( ??? ) można było oglądać w czasie rzeczywistym poprzez Internet. Co się tyczy samych startupów, to były one dość zróżnicowane. Jest jednak pewna tendencja do powielania zachodnich pomysłów. BTW czy Polakom brakuje kreatywności?

Zdaniem jury jak i widzów zwycięzcą został projekt Erasumuse zaadresowany do studentów pragnących skorzystać z programu Socrates-Erasmus. W zamierzeniach ma on być jeśli dobrze rozumiem platformą (portalem społecznościowym) umożliwiającą zebranie wszystkich informacji przed planowanym wyjazdem na stypendium. Początkowo sceptycznie podchodziłem do tego pomysłu, ale jak się dłużej zastanowić to jeśli z portalu tego mieliby korzystać studenci z całej Europy to ma on predyspozycje do tego, aby odnieść sukces. Listę pozostałych nagrodzonych można zobaczyć na blogu Antyweb. Natomiast realcja w formie video znajduje się na blogu Mediafun Cafe

Jadę na Democamp

Właśnie zrobiłem rezerwacje na sobotnio-niedzielny Democamp odbywający się w Poznaniu. Tematyka startupów stała mi się ostatnio dość bliska, gdyż sam aktualnie pracuję nad jednym autorskim projektem. Kto wie, może któregoś dnia sam znajdę się po stronie prezentujących swój pomysł, więc póki co warto zobaczyć jak to robią inni zanim samemu przyjdzie stanąć przed publicznością. Jeśli kogoś ten temat zainteresował to polecam blog Antyweba oraz serwis Techcrunch. W przypadku, gdy samemu chce się śledzić pojawiające się polskie startupy to zapraszam na Startups.pl Informacje na temat prezentowanych witryn biorących udział w Democampie można znaleźć tutaj.

Spring Framework 3.0.0.M3 i Maven

Ostatnio zdarza mi się częściej używać Mavena, co jest generalnie ciekawym doświadczeniem, aczkolwiek czasami frustrującym. To ostatnie dopadło mnie przy próbie integracji ze Spring Framework. Na stronie projektu pokazany jest przykład integracji Springa z Mavenem. Repozytoria, z których można pobrać Springa są następujące:

  
   springsource-milestone
   http://repository.springsource.com/maven/bundles/milestone
  
  
   springsource-release
   http://repository.springsource.com/maven/bundles/release
  
  
   springsource-external
   http://repository.springsource.com/maven/bundles/snapshot
  

Przeglądać repozytoria można pod tym adresem. Teraz przyszedł czas, żeby zdefiniować zależności wskazujące na biblioteki jakich chcemy użyć w naszym projekcie. Tutaj mała wzmianka. Nazewnictwo artefaktów uległo zmianie w stosunku do poprzednich wydań Springa, więc migracja ze starszych wersji dla projektów używających Mavena może okazać się kłopotliwa.

    
        org.springframework
        org.springframework.core
        3.0.0.M3
  

Wydawać by się mogło, iż to już wystarczy. Niestety nie. Przy próbie ściągnięcia bibliotek okazuje się, że w repozytorium Springa nie ma wszystkich bibliotek, z których korzysta Spring. Prawdę mówiąc na tym etapie utknąłem. Na szczęście, ktoś wcześniej miał podobny problem i zasugerował dodanie repozytorium Atlassiana.

    
        atlassian-m2-repository
        https://m2proxy.atlassian.com/repository/public
    

Powyższe przygody sprawiają, że ciśnienie Ci wzrasta. Problem z zależnościami jest częstym przeżyciem dla użytkowników Mavena. Nie wiem do końca z czego to wynika? Czy problem leży po stronie twórców Mavena? Czy może ludzie, którzy umieszczają swoje biblioteki w publicznych repozytoriach nie zawsze dbają w należyty sposób o to, aby pobranie bibliotek odbywało się bezproblemowo?

Dołączenie źródeł do Eclipse'a za pomocą Mavena

Ciekawą cechą mavenowego pluginu dla eclipse'a jest możliwość dołączenia dokumentacji do używanych bibliotek. Odbywa się to w bardzo prosty sposób. Mając stworzony projekt przy użyciu Mavena w linii poleceń wpisujemy standardowe polecenie generujące niezbędne pliki potrzebne do rozpoznania naszego projektu przez Eclipse'a, ALE czynność tą popełniamy z dodatkowym parametrem:

mvn eclipse:eclipse -DdownloadSources=true

Prawie gotowe! Jeśli wcześniej mieliśmy otwarty owy projekt w Eclipsie, to wystarczy w Package Explorerze (czy też w Navigatorze) kliknąć na katalog z nazwą projektu i wcisnąć F5 w celu odświeżenia konfiguracji projektu. Od tego momentu cieszymy się możliwością przeglądania dokumentacji używanych bibliotek. Dzieje się tak po najechaniu myszką na nazwę klasy albo metody.

Załapałem się

Uff zdążyłem... Na blogu Grzegorza Dudy dowiedziałem się, że Atlassian zrobił promocję i umożliwił zakup rocznej licencji na JIRA i Confluence (po $5.00 za każdy produkt, co przy ASTRONOMICZNYCH cenach tych produktów wydaje się być okazją). Zakup licencji zawiera roczny maintence. Należy również wspomnieć, iż owa licencja obejmuje możliwość użytkowanie oprogramowania przez pięciu użytkowników, co w moim wypadku w zupełności wystarcza. Przy zakupie była opcja przedłużenia licencji na kolejne dwa lata co również uczyniłem. Szczerze mówiąc, jak zobaczyłem, że termin promocji upływa 24 kwietnia nie wgłębiałem się w warunki licencji tylko szybko zabierałem się za rejestrację, gdyż nie byłem pewien w obrębie jakiej strefy czasowej odbywa się owa promocja, a tu należy wspomnieć, że siedzibą Atlassiana jest Australia. W każdym razie udało się. :)

Pozdrawia szczęśliwy posiadacz JIRA i Confluence

Wielożeństwo czyli integracja Mavena z ICEfaces 1.8.0 i Tomahawk 1.1.8

Niedawno znalazłem się na zielonej trawce, więc jest trochę więcej czasu na rzeczy na które wcześniej go brakowało. Przy okazji pracy przy swoim prywatnym projekcie chciałbym zaprezentować integrację ICEfaces 1.8.0 z Tomahawk 1.1.8 przy użyciu Mavena. Jako kontenera serwletów użyę Tomcata 6.

Tak sie składa, że na dniach wyszła stabilna wersja ICEfaces w wersji 1.8.0. Jednakże o ile się nie mylę, to wciąż brakuje w niej gotowych walidatorów (np. e-maila, czy też porównania dwóch haseł przy ekranie z rejestracją). Te dobrodziejstwa są natomiast dostępne w Tomahawk. Niby są to małe rzeczy, ale po co się nadmiernie meczyć? Więc do roboty...

Ze strony ICEfaces pobieramy specjalną paczkę przeznaczoną dla Mavena i po rozpakowaniu kopiujemy ją do katalogu naszego lokalnego repozytorium. W moim Ubuntu jest to katalog .m2, który znajduje się w moim katalogu domowym natomiast dla systemu Windows będzie to C:\Documents and Settings\twójlogin\.m2\repository

Teraz esencja czyli pom.xml. Plik ten został stworzony na podstawie jednego z tutorialowych przykładów ICEfaces. Niestety nie może być zbyt pieknie. Owy pom trzeba w niektórych miejscach przeedytować, aby wszystko razem zgodnie współpracowało. Odpuszczę sobie zbędne gadulstwo, tylko zamieszczę poniżej końcową jego wersję:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>pl.syllepsa</groupId>
<artifactId>myapp</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>myapp Maven Webapp</name>
<url>http://maven.apache.org</url>
<build>
<finalName>myapp</finalName>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>tomcat6</server>
</configuration>
</plugin>
</plugins>
</build>

<repositories>
<repository>
<id>jboss-maven-repository</id>
<url>http://repository.jboss.com/maven2</url>
</repository>
</repositories>


<dependencies>
<dependency>
<groupId>org.apache.myfaces.tomahawk</groupId>
<artifactId>tomahawk</artifactId>
<version>1.1.8</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-comps</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-facelets</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
<exclusion>
<artifactId>commons-logging-api</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<profiles>
<profile>
<id>tomcat6</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf-version}</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf-version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-el</groupId>
<artifactId>commons-el</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>commons-discovery</groupId>
<artifactId>commons-discovery</artifactId>
<version>0.4</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<properties>
<!--
since no more versions of jsf1.1 are being developed, just
jsf-version property for jsf1.2
-->
<!-- <jsf-version>1.2-b19</jsf-version>-->
<jsf-version>1.2_12</jsf-version>
</properties>
</project>

W przykładzie Timezone7 z tutoriala ICEfaces prezentujacego integrację z Mavenem (przykład jest na miejscowym forum) wszystko wygląda pięknie, ale nie działa. Należy jeszcze poddać edycji plik web.xml i ustawić na wartość false parametry:

1. com.sun.faces.validateXml
2. com.sun.faces.verifyObjects

Na koniec w konsoli wpisujemy: mvn tomcat:deploy Przy założeniu, że macie stworzony jakiś przykładowy widok. Zakładam również, że skonfigurowany jest dostę do tomcata z poziomu mavena. Niejaki Pan Koziołek opisał to kiedyś dokładnie.

To chyba tyle. Powinno śmigać.

Korzystając z okazji życzę Wam owocnego przeżywania Świąt Wielkiej Nocy, a po Świętach uczestnictwa w wielu ciekawych projektach.

Mariusz

Spring BlazeDS

Wczoraj niezmiernie ucieszyła mnie informacja na InfoQ o tym, że SpringSource połaczył swe siły z Adobe w projekcie Spring BlazeDS. Na początku powinienem wspomnieć coś na temat samego projektu BlazeDS.
Otóż BlazeDS jest technologią uruchamianą po stronie serwera umożliwiającą komunikację pomiędzy Javą a technologią Adobe Flex i Adobe AIR, które pełnią funkcję widoku. Komunikacja odbywa się za pomocą protokołu AMF lub SOAP. Jakiś rok temu testowałem przykładowy kod korzystając zarówno z AMF jak i SOAP i pewnie nikogo to nie zdziwi, ale komunikacja przez AMF postępowała bardziej chyżo.
Co natomiast daje nam Spring BlazeDS ? Ano to, że mamy teraz dostęp do BlazeDS MessageBrokera jako do beana Springa. Dokładniej mówiąc oddzielnie trzymana jest (raczej niezmienna) konfiguracja BlazeDS, która zawiera definicję właściwości kanału AMF i oddzielnie konfigurowane jest źródło danych znane powszechnie z aplikacji Springowych.

Wydaje mi się, że wciąż konieczne jest używanie skrypletów w Action Scripcie dla akcji wysyłających dane do serwera. Może kiedyś będzie to rozwiązane przez projekt opakowujący komponenty Flexa w JSF. Wiem, że takowy już istnieje, ale go już dawno nie śledziłem.

Odnośniki:

http://www.infoq.com/news/2009/01/spring-adobe-blazeds
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://blog.springsource.com/2008/12/17/using-spring-blazeds-integration-m1/