z2-Environment

h1. Z2-Environment version 3.0

Version 3.0 is in progress

The main goals for 3.0 is to provide features that simplify user adoption.

h2. Simplified Entry-Level Operations

In order to reduce the initial usage barrier, the following should be possible (or simplified)

* Have a system layout consisting of a number of auto-discovered co-located file system repositories

** Much like the dev repo but actually based on the FSCR and "always armed"

** Benefit: Supports Git-branching approaches out of the box

** Benefit: Allows System Releases as a single ZIP to be exploded without any online access (a regular "copy" deployment)

* Provide consistent and complete system export

** Support binary or source-preserving export

** Provide clean component name escaping so we can also export mvn-provided artifacts if desired

** so we can offer a complete base distribution as binary download

** Running samples means to clone co-located Git Repos

** Make re-binding of repository locations simpler (e.g. a remote repo becomes a local FS repo after export)

* Support single-process mode (e.g. no Worker mode - move worker support into an add-on)

h2. Free Web Container Choice

It should be possible to use a Web Container of choice, as long as it is Jetty or Tomcat. Our tests indicate that it should be simple to programmatically control any pre-installed instance.

* Provide a web container resource that hooks up with a pre-configured web container OR a self-hosted web container

* This will require some creative business with the servlet/jsp and Web Container class path

h2. Improvements

* Provide a z2 for dummies introduction that starts with simple, include-based web apps

* Seamless support of Maven repositories (see [[V23]], [[maven_repo_support]])

** Including install into repository from z2

* Use string revisions rather than longs (so that natural versions are better supported)

* Introduce "Java Templates", Java (and others) Component configuration made simpler (see [[smart_props]])

* Port add-ons and samples to maven repos for external artifacts

h2. Proposals

h3. Local Install Layout

By means module virtualization (already today via the module name property of the dev repo) we can essentially turn anything that has a "z.properties" into a component and use a declared name as the module "namespace".

Combined with an "adapter component type" concept we can introduce for example

* Tomcat Adapter Component: Tells the Tomcat based web container integration about the location of a Tomcat installation.

* and similarly for other component types that depend on "local/external" defined resources

The follwing _typical_ layout is suggested:

<pre>

+-<tomcat-folder>

|  +- z.properties  (adapter declaration)

|  +- LOCAL (tagging)

|  +- <whatever tomcat stuff>

|

+-zlight

|  +-zlight.core (core)

|  +-zlight.base (base stuff)

|  +-<more fs repos>

|

+-<armed module 1>

+-<armed module 2>

|

+-<git repo 1>

</pre>

h3. Web Container Integration

As outlined above, we will support re-use of existing pre-configured web container instances.

h3. Repository Export

We will enhance the repository export so that given a number of repository component names (possibly including mvn repos), a complete export, in source or binary, will be put into a structure as outlined above. 

* Repository Component Names can be mapped

* We will introduce a component name escaping pattern to support maven originated components as well 

h3. Review of Software Component Responsibilities

+core+

* Component and Module Model

* Component Types:

** System State

** Java / Compiler

** "main" programs

** "any"

+base+

...