This is a design document for the Kauri binary distribution, not documentation of the actual situation.

What this is about: building the kauri.zip or kauri.tar.gz that we make available for download.

Background

Use cases

Use cases of the developer

Someone wants to create an application using Kauri as framework.

What does this person need to do?

  • install Kauri
  • install Maven
  • possibly use a Maven archetype to create initial project layout
  • add Kauri dependencies to his project's pom as needed
  • Maven will download the dependencies from Kauri's public Maven repo. Strictly speaking, these dependencies are as well available in the Kauri binary dist, so don't need downloading again, but this is not so important (if one really cares, he could always add a repository pointing to the binary dist).
  • run Kauri to test
    • use kauri script in kauri/bin dir from dist
    • Kauri should automatically use as repository:
      • (1) the one in the Kauri binary dist and
      • (2) the developer's one, determined in the same way as Maven does:
        1. System property maven.repo.local
        2. $HOME/.m2/settings.xml, xpath settings/localRepository
        3. System.getProperty("user.home") + ".m2" + "repository"
        4. (Nota: huidig Windows script veronderstelt M2_REPO env var, wordt niet herkend door mvn zelf, maar naamgeving is afkomstig uit eclipse)
  • make testcases with launch Kauri internally

Use case of the deployer

Someone created an application with Kauri, it now needs to be deployed on a server.

Deploy an application using Kauri as the runtime environment

  • install Kauri
  • get a Kauri application = kauri.xml + set of modules and dependent libraries in maven-repo-style dir layout [possibly: non-jarred modules?]
  • there could be conflicts between the Kauri version installed and the Kauri artifacts referenced in the application (both in kauri.xml and classloaders withing the module jar). Solutions include:
    • allowing projects to be Kauri-version agnostic. See also http://kauriproject.org/issues/ticket/34
    • foresee an option to override/ignore the version of the kauri artifacts at runtime

Deploy an application on a JEE servlet container (a.k.a. war deployment)

(just a thought experiment, not an urgent need)

  • would not be a deployment form in which Kauri ships
  • but rather a deployment form for a concrete Kauri-based application
  • the war should contain everything: module jars, kauri jars, all dependency jars, configs, ... : dropping the war in a servlet container would be enough to run the application.

What needs to be included in the dist + proposed directory layout

bin/kauri.sh
    kauri.bat
lib/
    Maven2 style repo with all jars (kauri + deps)
samples/
    sources of the sample modules + their kauri.xml files
README.txt
LICENSE.txt

TODO: include licences of third party software. Automated way to do this? Need to manage them manually in the SVN? Also for transitive deps? (would think yes, since we're distributing those jars too)

Other things we could include:

  • api docs

Things learned from Daisy and others?

Anything relevant?

  • Make sure the scripts work also on Solaris: defining variables and exporting them need to be done in two steps

Kauri startup script

References libs from KAURI_HOME
Automatic detection of HOME directory? (should be possible... see ant)

Implementation of the binary dist build