Z2-Environment version 3.0¶
Version 3.0 is in EXPERIMENTAL and not in development anymore. Feature will migrate to 2.x as fits.
It was 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.
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
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)
- 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.
Local Install Layout¶
Introducing an extended file system repo support and better split of resource and work dirs, the follwing typical layout is suggested:
| +-boot (boot repo)
| +- zding-essentials
| +- zding-jetty
| +- zding-devtools
| +- zding-tomcat
+-<armed module 1>
+-<armed module 2>
+-<git repo 1>
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¶
- Component and Module Model
- Component Types:
- System State
- Java / Compiler
- "main" programs