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. Move to org domain

* We will refactor all core code into *org.z2env*.

h2. Simplified and lighter setup

* Provide completely local installation via a root repository that features local FSCR addon repositories

* Provide a stripped-down base installation that is essentially only capable of running main programs.

* Split the base addon into individual addons for:

** dev tools (z2unit, eclipsoid)

** tomcat hookup

** worker support

** etc.

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. 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. 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

* Drop "I" interface notation

* Drop resource instance on every invalidation.

* Define component name escaping for the file system repo helper

* Introduce boot repository *at* Z2_HOME into ComponentsManager 

** Auto-discover other repos at Z2_HOME

** Default "." as dev repo workspace

** launch purely from "java -jar z.jar"

** Introduce moduleName property for "free-floating" components

** Introduce repository adapter type.

* Folders for operation

** org.zding.home --> shared repos entry point, work and data store (==> repos, in particular DEV repo must use folder-unique work key). Defaults from Z2_HOME.

** org.zding.dev.workspaces --> workspaces to check for dev repo component overrides. Defaults from "."

* Use /code instead of /java to be more agnostic to the language in use

h2. Proposals

h3. Local Install Layout

Introducing an extended file system repo support and better split of resource and work dirs, the follwing _typical_ layout is suggested:

<pre>

+-<$CATALINA_HOME>

|

+-zding

|  +-boot (boot repo)

|  +-root

|    +- zding-essentials

|    +- zding-jetty

|    +- zding-devtools  

|    +- zding-tomcat  

|  +-zding.jar

|

+-<armed module 1>

+-<armed module 2>

|

+-<git repo 1>

</pre>

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"