JasperReports, iText, Groovy – poranne zamotanie

W projekcie zaczynamy używać biblioteki iText i JasperReports. Wszystko ładnie pięknie, ale:

  • iText mamy w wersji 5.0.0.
  • JasperReports w wersji 3.5.3.
  • Używamy mavena.
  • JasperReports używa iText

Pierwszy problem to dość poważna wpada ekipy od iTexta. Otóż wersji 5 nie ma w repo mavena. Dopinamy więc ja ręcznie. Następnie okazuje się, że JR wykorzystuje iText, ale w wersji 2. niby wszystko bangla, ale różnica pomiędzy iText 5 i 2 jest niewielka jednak bardzo bolesna. Polega na zmianie nazw pakietów. Zamiast com.lowagie.text w wersji 5 mamy com.itextpdf.text. Zatem musimy mieć dwie różne biblioteki w projekcie. Jeżeli w mavenie podepniemy z rozpędu iText 5 do grupy com.lowagie to oczywiście wersja 2 zostanie zignorowana przy sprawdzaniu zależności JR. Spowoduje to brak klas z pakietu com.lowagie.text i tym samym radosna wyjebkę całości. Poniżej poprawny kawałek pom.xml:

Listing 1. Poprawnie złożony pom.xml


	itext
	itext
	5.0.0
	system
	${basedir}/libs/iText.jar


	com.lowagie
	itext
	2.1.7


	jasperreports
	jasperreports
	3.5.3

tak będzie git.

Kolejna ciekawostka to błąd java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException w trakcie generowania raportu. Okazuje się, że jeżeli używa się iReport do tworzenia szablonów to do tagu jasperReport jest dodawany atrybut language=”groovy”. Na rozwiązanie problemu są dwie drogi. Pierwsza dopiąć Groovy, druga wyjebać atrybut. Pierwsza metoda wymaga jednak użycia paczki groovy-all. Dodajemy zatem:

Listing 2. groovy-all w pom.xml


	org.codehaus.groovy
	groovy-all
	1.7.0

Zaletą tego rozwiązania jest możliwość, dania użytkownikom iReport i powiedzenie, by sami ładowali raporty na serwer.

koniec

uff…

Leave a Reply