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.

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)

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

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

Proposals¶

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:

+-<tomcat-folder>
|  +- z.properties  (adapter declaration)
|  +- LOCAL (tagging)
|  +- <whatever tomcat stuff>
|
+-zding
|  +-addons
|    +- zding-essentials
|    +- zding-jetty
|    +- zding-devtools  
|  +-zding.jar
|
+-<armed module 1>
+-<armed module 2>
|
+-<git repo 1>

Further requirements¶

• Autodiscovery should provide a seamless transition between remote and local repositories.
• Functionality in a repository (such as devtools) should have a way to indicate (<name>/requirements.properties --> part in homeUp) that it requires other repositories (by name).

Web Container Integration¶

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

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"

base

...