V30 » History » Revision 13
Revision 12 (Henning Blohm, 03.12.2014 18:50) → Revision 13/18 (Henning Blohm, 08.01.2015 16:37)
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 adoption. h2. Simplified and lighter setup Entry-Level Operations In order to reduce the initial usage barrier, the following should be possible (or simplified) * Provide completely local installation via Have a root repository that features local FSCR addon repositories * Provide system layout consisting of a stripped-down base installation that is essentially only capable number of running main programs. auto-discovered co-located file system repositories * Split ** Much like the base addon into individual addons for: ** dev tools (z2unit, eclipsoid) repo but actually based on the FSCR and "always armed" ** tomcat hookup Benefit: Supports Git-branching approaches out of the box ** worker support ** etc. h2. Free Web Container Choice It should be possible Benefit: Allows System Releases as a single ZIP 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 exploded without any pre-installed instance. online access (a regular "copy" deployment) * 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. 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 * 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 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 extended file system repo support and better split "adapter component type" concept we can introduce for example * Tomcat Adapter Component: Tells the Tomcat based web container integration about the location of resource a Tomcat installation. * and work dirs, the similarly for other component types that depend on "local/external" defined resources The follwing _typical_ layout is suggested: <pre> +-<$CATALINA_HOME> +-<tomcat-folder> | +- z.properties (adapter declaration) +-zding | +- LOCAL (tagging) | +-boot (boot repo) +- <whatever tomcat stuff> | +-zding | +-root +-addons | +- zding-essentials | +- zding-jetty | +- zding-devtools | +- zding-tomcat | +-zding.jar | +-<armed module 1> +-<armed module 2> | +-<git repo 1> </pre> h2. 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). 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+ ...