Maven and Jelly

1. Maven and Jelly James Strachan

2. Introduction • Maven and Jelly are both Apache projects at Jakarta • http://jakarta.apache.org • Ultimately both will be top level projects inside Jakarta • Right now Maven is inside Turbine and Jelly is inside Commons

3. Topics of Discussion • What is Maven • What is Jelly • Should we use these things? • How, what, why, when…

4. Maven • http://jakarta.apache.org/turbine/maven/ • It’s a Java project management and comprehension tool • Think a layer above Ant • Avoid us all hacking Ant build files

5. Build history • First there was make. But was not cross platform. • Ant came along as a Java-centric build system that was cross platform • We now spend lots of time hacking Ant’s build.xml files

6. Itches Maven Scratches • We should be able to share build.xml files • Often not much changes from project to project, other that the dependencies (classpath). • Maintaining real version information and setting the classpaths are a PITA

7. Early Maven… • In the early days, Maven used Ant • We shared Ant build scripts. • Customization was through Ant callbacks. • Worked OK, was slow but callbacks suck

8. Maven b5 onwards… • Along comes Jelly… • A more flexible front end to Ant. • Uses a goal library for Jelly which allow pre/post actions to be registered or goals to be replaced. • Goal library is a neat replacement for hacky Ant callbacks.

9. So how does Maven work? • You create a project.xml which describes your project • Project info (name, company, website etc) • Where the source code is • Where the unit test cases are • What the dependencies are

10. Then… • From the command line type maven -g • To see all the possible goals maven site:deploy • Will build all your code and website • run your unit test cases, create a report, javadoc, source code cross reference, CVS log, file activity…

11. Example project.xml <project> <id>foo<id> … <dependencies> <dependency> <id>log4j</id> <version>2.1.0</version> <dependency> <dependencies> </project>

12. What actually happens… • project.xml is used to create a POM (Project Object Model) • Its reusing Ant tasks under the covers • We are sharing (something like) build.xml documents across projects • A Jar repository is used to automatically download required jars and to set the classpath • All dependency information is automatically documented. It can be embedded into jar manifests too.

13. Maven Repository • A local repository and a list of remote repositories. • Supports mirroring and N-tier of repositories • New jars can be download • Repository can be shared across projects • Can be used for multi-version testing

14. What actually happens… • Its just reusing Ant tasks under the covers • We are sharing (something like) build.xml documents across projects • A Jar repository is used to automatically set the classpath • All dependency information is documented. It can be embedded into jar manifests too.

15. Plugins… • Maven is built around a plugin architecture • There’s already a lot of plugins. Type ‘maven –g’ and you’ll see. • The plugins are gonna grow and grow. • Plugins use the same repository, so no need to worry about setting classpaths… • As soon as a new plugin is written, we all get to use it, without hacking build.xml

16. Some plugins… • site:deploy – builds and deploys your entire developer website • dist:deploy – builds and deploys your distributions • test – runs your unit tests • test:single-test –Dtestcase=Foo • test:ui – runs the Swing JUnit TestRunner • Many others… • Eclipse plugin, Clover, WAR, EAR, JDiff, CVS log, project metrics, JDepend etc.

17. So main benefits of Maven • No more classpath blues when building • We are sharing (something like) build.xml documents across all projects • Real dependencies are documented and managed • We all get to share plugins added to Maven

18. Maven Reactor • Building lots of projects with interdependencies • Like Gump (http://jakarta.apache.org/gump) • Can be used for Continuous Integration, running combinations of versions of multiple projects. • Using workflow of builds, distributed across servers • Builds, runs test cases and creates reports

19. Continuous Integration • Early warning system when things break due to • Code changes • Different platforms (OS, JDK) • Different dependencies (e.g. change to XML parser or other dependent library) • We could reuse this infrastructure for doing integration testing across versions, platforms and different dependency sets.

20. Customizing Maven • Create project.properties, or local build.properties, or ~/build.properties • Write a plugin • Create maven.xml

21. Maven.xml • plugin.xml, project.xml and maven.xml are all Jelly scripts. • Can use POM beans like ${pom.build.sourceDirectory} <j:forEach var=“d” items=“${pom.dependencies}”/> <copy file=“${d.jar}” todir=“${foo}”/> </j:forEach>

22. Its Jelly time… • Java & XML based processing engine. • Superset of Ant build.xml language and JSTL • Allows mix and match of declarative and procedural XML languages. • Can include other XML languages like BPML, BPEL4WS, WSCI, WSDL invocations etc. • Turns any XML document into a ‘script’ that can be ran

23. Pluggable languages • Pluggable expression languages like JSP EL, Velocity, XPath etc. • Pluggable scripting languages, beanshell, JavaScript, Jython. • You can plug in your own XML languages or custom beans

24. Features • Simple and lightweight • Can be ran from command line, used in Maven, in applet, application server etc. • Open and extensible • XML Namespace URIs can be bound onto a Jelly Library • An XML tag name can be bound onto Java code via a Tag • Expressions can be used within the XML

25. Based on XML • Jelly scripts are parsed from SAX. • Can use HTML parser to use non-well formed Jelly scripts. • Jelly is based on an XML pipeline architecture. • A Tag can consume, emit, filter or transform the XML events of its body. • Very powerful, flexible scripting and XML processing engine • Ideal for processing XML, SOAP, Web Services etc.

26. Bean example… <price>${customer.orders.calculatePrice()}</price> <j:if test=“${message.header.foo = ‘abc’}> … </j:if> <j:forEach var=“order” items=“${bean.orders(‘uk’, foo)}”> <productOrder id=“${order.id}”> <amt>${order.amount}</amt> </productOrder> </j:forEach>

27. XML example… <x:forEach select=“$doc//food[@kind=‘cheese’]”> <x:if test=“bar = ‘abc’”> do something… </x:if> <foo> <x:expr select=“pizza[@topping]”/> </foo> </x:forEach>

28. SQL example… <sql:query var=“results”> select * from customer </sql:query> <j:forEach var=“cust” items=“${results.rowsByIndex}> <customer id=“${cust.id}”> <name>${cust.name}</name> </customer> </j:forEach>

29. Features • Can write tag macros in Jelly script or bind tags to beans • Very flexible. E.g. can be used to implement • JSTL, page templating system etc. • Maven build system • workflow languages • declarative integration scripts (WIS etc)

30. JellyUnit • Uses Jelly script to implement unit testing • Can mix and match beans, SQL, JMS, XML validation, XPath evaluation, SOAP calls, HTTP etc.

31. JellyUnit example <test:case name=“someTest“> <test:assert test=“${bean.xyz == ‘abc’”/> <x:parse var=“doc“xml=“foo.xml”/> <test:assert xpath=“$doc/foo/bar”> Found the bar! </test:assert> </test:case>

32. Summary • Maven is a great tool for managing and building projects • Increasingly Maven’s project based Continuous Integration and build/test workflow abilities will be invaluable • Jelly can be very useful in both unit and integration testing