Właśnie ukończyłem pisanie kolejnego artykułu, który jest opisem moich doświadczeń z integracji różnych projektów w celu zestawienia środowiska dla urozmaicenia lektury specyfikacji JPA. Z jego pomocą zamierzam jednocześnie czytać i programować, tj. tworzyć własne komponenty encyjne oraz wykonywać testy jednostkowe z nimi w roli głównej.
Nie tak dawno pisałem (a może jedynie myślałem o tym) o popróbowaniu się z TestNG. Było to w momencie, kiedy powracałem do lektury specyfikacji Java Persistence API (JPA), więc pomyślałem o połączeniu przyjemnego z pożytecznym, czyli o możliwości jednoczesnego testowania tego, co czytałem. Można było również inaczej postawić problem - najpierw próbować się z JPA, a później szukać wyjaśnień jej działania wertując kartki specyfikacji. Tak, czy owak nie chciałem jedynie relacjonować specyfikacji JPA, ale również prezentować możliwe zastosowania. Sprowokowało mnie to do zestawienia środowiska, w którym będę tworzył moje komponenty encyjne i aplikacje korzystające z nich oraz posiadał mechanizm wykonywania testów. Skoro dotykałem JPA to konieczna była baza danych - padło na Apache Derby. Do tego dorzuciłem Apache Maven 2 jako narzędzie spinające całość (i dostarczające wielu niewykorzystanych acz wielce produktywnych funkcjonalności), z Eclipse IDE w tle, co ostatecznie przemieniło się w bardzo produktywne środowisko do poznawania JPA w niezwykle praktyczny sposób - tworząc testy jednostkowe w trakcie lektury specyfikacji.
Początkowo miała to być jedynie relacja z moich doświadczeń, ale nie długo trwało zanim zorientowałem się, że wielkość materiału przekracza ramy relacji i wymaga stworzenia artykułu, co uczyniłem.
Jest to środowisko, które uatrakcyjni moją lekturę specyfikacji. Robi się w końcu coraz trudniej i możliwość zobaczenia tego, co się czyta wierzę, że jest ciekawym pomysłem na niwelowanie potencjalnych wybojów. Konfiguracja środowiska z wykorzystaniem JPA z Apache OpenJPA i Apache Derby oraz Apache Maven 2 i TestNG zapewnia mi powtarzalność wykonywania testów i jest jednocześnie ciekawym urozmaiceniem pogłębiania znajomości JPA. Tak "uzbrojony" jestem gotów do podjęcia się wyzwania rozpoznawania specyfikacji Java Persistence API w praktyce!
Artykuł zatytułowany jest Java Persistence API z OpenJPA i Derby oraz TestNG z Eclipse IDE w tle.
Mała uwaga: nie bardzo wiem po co wykonywać polecenie:
OdpowiedzUsuńmvn -Declipse.workspace=C\:/.eclipse/jpa eclipse:add-maven-repo
skoro za chwilę i tak będziemy korzystać z wtyczki mavena dla eclipse.
Podobnie nie widzę sensu w takiej sytuacji w definiowaniu w eclipse zmiennnej M2_REPO bo wtyczka mavena dla eclipse z niej nie korzysta.
Być może nieporozumienie polega na tym że mamy tutaj do czynienia z dwoma różnymi programami, które w zasadzie ze sobą nie współpracują, tzn.: wtyczką eclipse dla mavena czyli maven-eclipse-plugin i ze wspomnianą wyżej wtyczką mavena dla eclipse czyli m2eclipse.
Napisałem "w zadadzie", gdyż na obecnym etapie rozwoju m2eclipse (brak funkcji a'la "Java Project from Existing Maven2 POM"), najwygodniej jest rzeczywiście użyć na początku polecenia "mvn eclipse:eclipse" czyli skorzystać z "konkurencyjnej" wtyczki, zaimportować projekt, wyczyścić "Build Path" i "enablować" Maven2.
Właśnie przed chwilą wpadłem na informację, że najnowsza (2.4-SNAPSHOT) wersja wtyczki maven-eclipse-plugin ma cel specjalnie przeznaczony do współpracy z m2eclipse ("mvn eclipse:m2eclipse"), którego wykonanie zastępuje wszystkie opisane wyżej kroki.
OdpowiedzUsuńDzięki za bardzo przydatny artykuł. Przeszedłem Twojego tutoriala bez Eclipsa ale za to z bazą PostgreSQL.
OdpowiedzUsuńMam następujące uwagi:
1. w pliku persistence.xml dopisałem:
property name="openjpa.QueryCompilationCache" value="false"
2. Sugeruje wymianę metody testowej: sprawdzIloscPracownikow
na: usunPracownika.
U mnie wygląda to mniej więcej tak.:
public class AntekTest {
private EntityManagerFactory emf;
private EntityManager em;
private Antek antek;
@BeforeClass
public void setUp() {
emf = Persistence.createEntityManagerFactory("AntekPU");
em = emf.createEntityManager();
}
@Test
public void createAntek() {
Antek a = new Antek();
a.setName("Antek");
EntityTransaction tx = em.getTransaction();
tx.begin();
em.persist(a);
tx.commit();
antek = a;
}
@Test(dependsOnMethods = { "createAntek" })
public void dropAntek() {
EntityTransaction tx = em.getTransaction();
tx.begin();
Antek a = (Antek)em.find(Antek.class,antek.getId());
assert antek.getName() == a.getName() : "Expect getName()=Antek, but there is: " + a.getName();
em.remove(a);
tx.commit();
}
@AfterClass
public void tearDown() {
em.close();
emf.close();
}
}
Co ciekawe, w logu SQL z wykonania takiej procedury nie ma select'a który powinień przypadać na wykonanie metody em.find(...). Oznacza, to że OpenJPA zakeszowało sobie jednego "Antka".
Cześć jonsnow!
OdpowiedzUsuńWidzę, że przegapiłem kilka ciekawych informacji o współpracy Eclipse i M2. Dzięki!
Gdzie znalazłeś informację o nowym zadaniu eclipse:m2eclipse wtyczki eclipse?
Jacek
Cześć Antoni!
OdpowiedzUsuńAd 1. Dlaczego porzebny jest ten parametr?
Ad 2. Dobra uwaga!
Jacek
Właśnie doceniłem komentarz Antoniego Jakubiaka. Walczyłem całą sobotę z maven-surefire-plugin i OpenJPA i nie mogłem dojść dlaczego wciąż mam BUILD ERROR. Okazało się, że po zastosowaniu
OdpowiedzUsuń<property name="openjpa.QueryCompilationCache" value="false" />
testy napisane w TestNG zaczęły ponownie działać. Piękno M2, kiedy uaktualnia wersje SNAPSHOT.
Dzięki Antoni! Opiszę moje doświadczenia w kolejnym wpisie w Notatniku.
Jacek