20.1.2 Various parts of the structure

20.1.2.1 The Project Declaration (root pom.xml)

Maven organizes all build and dependency-management aspects of your project at build time in the pom.xml. 
In the typical multi-module approach Kauri proposes this is called the 'root-pom'.  It will hold:

• a clear list of the various modules this project is composed off
• all shared information elements for the various contained modules
  (so specific modules just bear a minimal pom.xml while inheriting the common parts)

20.1.2.2 The Various modules and their contents

Each module being produced in a project requires its own subdirectory (holding its proper pom.xml)  This matches the maven approach to let each pom.xml be responsible to produce one artifact.  In the case of kauri-modules these artifacts are classic java jar files with an optional KAURI-INF map in them.

The typical maven approach is to let

{module-dir}/src/main/java	Hold the java classes, organized in packages that will be compiled to {module-dir}/target/classes and included in the root of the jar.
{module-dir}/src/main/resources	Hold additional 'resources' to be mixed in with the classes mentioned above.
{module-dir}src/main/test	Hold the junit test classes for build-time tests. (Not to be included in the jar)

To that Kauri adds:

{module-dir}/src/main/kauri

A place-holder for all kauri-specific stuff that gets folded into the jar under the mentioned KAURI-INF folder.

In that folder the following the following elements/positions have a specific function:

• KAURI-INF/spring/**.xml
• Various sping-framework bean-xml files that describe the dependency injection and configuration of the (see the Spring config reference for more details)
• Note that a selection of active bean-XML files can be made through the -p runtime-mode switch when launching the Kauri runtime.
• KAURI-INF/classloader.xml
• A list of dependencies that should be loaded for this module to run properly.  (see classloading.xml reference for syntax details)
• Note that this file will automatically be generated during build in most cases.

Next to these, you'll typically find also

• KAURI-INF/router.groovy
• A (groovy) scripted uri-matching dispatcher. (see Routing to understand what it is about, or the syntax reference to learn how to modify and extend)
• KAURI-INF/templates
• A set of xml files that are using the kauri template language to generate parts or structures of page impressions used in your web-site.
• We typically further split them in 3 groups:
• snippets: cut-paste insert-able (xhtml) pieces that occur at various places
• macros: libraries of callable macros that produce (xhtml) pieces based on some logic
• layout: generic page-layou structures that can be inherited from.
• KAURI-INF/pages
• Full page impressions that are often directly mapped on the public uri of your site.  These often are also 'templates' which are offering full page impressions. They typically combine layout-inheritting, snippet-inclusion and macro-calling, so they aggregate the lower level stuff from the templates folder.
• Additionally this folder-name is typically selected for so called ' pages' routing: a flexible mechanism to automatically upgrade chosen file and path-names to uri-template expressions used for matching.  This technique is specially useful for Prototyping

20.1.2.3 Test and Deploy settings (conf, module-source-location.properties,...)

Lastly the project-folder will hold a number of runtime oriented files that allow for easily running and testing the combined modules in their project setting.

• conf/**
• This folder holds all configuration for the application-global behaviour as well as for the individually deployed modules. More details are described in the documentation on Configuration as well as the wiring.xml and the connectors.xml reference.
• module-source-location.properties
• This file allows to test specific modules in so called source mode, which picks up 'live' changes to various source files holding interpreted languages in the system (ie templates, css, js, groovy, etc ). Since this avoid rebuilding/packaing of the module it can be a great way to speed up your prototyping.