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.
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:
- System property maven.repo.local
- $HOME/.m2/settings.xml, xpath settings/localRepository
- System.getProperty("user.home") + ".m2" + "repository"
- (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
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
- foresee an option to override/ignore the version of the kauri artifacts at
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
Maven2 style repo with all jars (kauri + deps)
sources of the sample modules + their kauri.xml files
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:
Things learned from Daisy and others?
- 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
- Maven release plugin: automates the process of updating pom version numbers,
committing, tagging, deploying, moving pom versions to next dev version,
- Personal judgment: somewhat interesting, but is rather orthogonal to the
problem of assembling the dist
- Assemblies: seems like what we need:
- Custom plugins: if our needs wouldn't fit in the Assemblies system