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/
• Its 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 Ants 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 sitedeploy
• 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

• ltprojectgt
• ltidgtfooltidgt
• ltdependenciesgt
• ltdependencygt
• ltidgtlog4jlt/idgt
• ltversiongt2.1.0lt/versiongt
• ltdependencygt
• ltdependenciesgt
• lt/projectgt

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
• Theres already a lot of plugins. Type maven g
  and youll 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

• sitedeploy builds and deploys your entire
  developer website
• distdeploy builds and deploys your
  distributions
• test runs your unit tests
• testsingle-test DtestcaseFoo
• testui 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
  
• ltjforEach vard itemspom.dependencies/gt
• ltcopy filed.jar todirfoo/gt
• lt/jforEachgt

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

• ltpricegtcustomer.orders.calculatePrice()lt/pricegt
  
• ltjif testmessage.header.foo abcgt
• lt/jifgt
• ltjforEach varorder itemsbean.orders(uk,
  foo)gt
• ltproductOrder idorder.idgt
• ltamtgtorder.amountlt/amtgt
• lt/productOrdergt
• lt/jforEachgt

27
XML example

• ltxforEach selectdoc//food_at_kindcheesegt
• ltxif testbar abcgt
• do something
• lt/xifgt
• ltfoogt
• ltxexpr selectpizza_at_topping/gt
• lt/foogt
• lt/xforEachgt

28
SQL example

• ltsqlquery varresultsgt
• select from customer
• lt/sqlquerygt
• ltjforEach varcust itemsresults.rowsByIndex
  gt
• ltcustomer idcust.idgt
• ltnamegtcust.namelt/namegt
• lt/customergt
• lt/jforEachgt

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

• lttestcase namesomeTestgt
• lttestassert testbean.xyz abc/gt
• ltxparse vardoc xmlfoo.xml/gt
• lttestassert xpathdoc/foo/bargt
• Found the bar!
• lt/testassertgt
• lt/testcasegt

32
Summary

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