Z2-Environment version 3.0¶

Version 3.0 is in progress. It is developed here: org.z2env.

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

Move to org domain¶

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

(DONE)

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.

(DONE)

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

(DONE for Tomcat)

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)

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
• Use /code instead of /java to be more agnostic to the language in use (postponed)
• Drop workunit expectation in (e.g.) SVNCR.

Proposals¶

Local Install Layout¶

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

+-<$CATALINA_HOME>
|
+-z2env
|  +-boot (boot repo)
|  +-roots
|    +- zding-essentials
|    +- zding-jetty
|    +- zding-devtools  
|    +- zding-tomcat  
|  +-z.jar
|
+-<armed module 1>
+-<armed module 2>
|
+-<git repo 1>

(DONE)

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

Review of Software Component Responsibilities¶

core

• Component and Module Model
• Component Types:
  • System State
  • Java / Compiler
  • "main" programs
  • "any"