z2-Environment

h1. IntelliJ z2 plugin

The z2-plugin for IntelliJ IDEA simplifies development with the z2-environment. 

The following features are supported as of version 1.0:

* *[[IntelliJ_z2_plugin#Launching|Launching]]:* Start your z2-environment on your local machine from the IDE

* *[[IntelliJ_z2_plugin#Managing z2-modules|Managing z2-modules]]:* z2-modules can be created and deleted on demand

* *[[IntelliJ_z2_plugin#Arming modules|Arming modules]]:* Armed z2-modules become active after z2-Sync.

* *[[IntelliJ_z2_plugin#z2-sync|z2-sync]]:* Synchronize your local changes with the z2-environment

* *[[IntelliJ_z2_plugin#z2-dependency-resolution|z2 dependency resolution]]:* Resolve missing dependencies from the z2-environment

* *[[IntelliJ_z2_plugin#z2-Module wizard|z2-Module wizard]]:* Create new z2-modules with or without Spring support

* *[[IntelliJ_z2_plugin#z2-Properties editor|z2-Properties editor]]:* Provides completions and documentation for z2-properties files

h2. Installation

TODO

h2. Prerequisites

The IntelliJ z2-plugin requires a certain project layout. The z2-repositories should be checked out directly beneath the project folder

(i.e. as siblings of the .idea folder). You have to checkout at least z2-core (e.g. z2-base.core) and the repository containing the modules

you want to work with (let's call it "modules"). If you are using Git you must not necessarily clone z2-base.core and z2-addons etc. - 

however if you are using subversion it might be easier to check out the whole trunk making it easier to update the sources with one command.

The important point is that the project structure should look like this:

<pre>

.../my-project

     /modules

       /my-module-A

         ...

       /my-web-app-X

         ...

       /my-web-app-Y

         ...

     /z2-base.core

      ...

</pre>

Where my-module-A and my-web-app-* are arbitrary z2-modules.

Note that this is slightly different to the Eclipse approach when working with subversion. In Eclipse it's much easier to checkout a project from subversion into

the workspace (note the an Eclipse project is more or less on the same level than an IntelliJ module). So in Eclipse you checkout projects and delete them on demand

(after you committed your changes). In IntelliJ you _map_ and _unmap_ modules into the IDE which is similar to the Eclipse-Git approach.

This means that all checked out repositories automatically belong to the z2 dev-repository. Of course their module remain inactive as long as they are unarmed.

h2. Preferences

The z2-plugin preferences can be found at Project-Settings -> z2-Environment. The typically development settings like host-name=localhost, port=8080, user=z* and password=z are set by default.

Once a z2-environment is up and running the settings can be verified using "Test connection...".

The field "z2 Home Directory" must point to the folder where the z2-core is installed. This location can be chosen by the file picker dialog or by "Search z2-Home" button.

The latter one searches the directory structure within your IntelliJ project folder for a valid z2-Home location. The z2-Home location defines which z2-environment will be started when 

launching the z2-environment from the IDE.

h2. Launching

Once the z2-Home is defined, the z2-environment can be launched from the IDE: Select *Tools* -> *Launch z2-environment...*.

This will start the z2-environment on your local machine using your local OS JDK (not the one defined in IntelliJ). Beside

the standard z2-Swing window the server output is logged inside an IntelliJ tool window (see *View* -> *Tool Windows* -> *z2-environment*).

Logs from the z2-server are displayed in red text color while output from the z2-plugin is displayed in blue.

h2. Managing z2-modules

Once the project is setup, the required z2-repositories are checked out and the z2-Home setting is defined in the preferences, 

you can create and remove z2-modules on demand. The z2-plugin provides the "Manage z2-module" icon in the IntelliJ toolbar.

It opens a dialog containing a check-box tree with the repositories at the first level and the modules on the second level

(additional modules can also occur on the first level). 

Now select the modules you want to work on and unselect those you want to get rid off. 

Newly selected modules are displayed in green with a prefixed '+' while modules which are about to be removed are displayed in 

red with a prefixed '-'. When pressing ok the newly selected z2-modules become visible in the IDE as IntelliJ modules with correctly 

assigned source folders, while unselected modules are removed from the IDE. Please note that this is just a mapping step, 

no files and directories are physically deleted - with one exception: If you open a z2-module in the IDE, work with it and remove it later on, 

the initial arming state is restored. So if you open an unarmed z2-module and arm it while working with it while automatically be unarmed when you remove

the module from the IDE by deleting the corresponding LOCAL file.

h2. Arming modules

Modules inside the dev-repository become active once they are armed (which means a file called "LOCAL" exists inside the module folder).

Repositories checked out as siblings to z2-base.core belong automatically to the dev-repository. You can arm and disarm modules in IntelliJ 

using the context menu in the project view: Right click a module (or any file inside a module) and choose "Arm z2-Module" or "Disarm z2-Module" resp.

When multiple modules are selected you can toggle the arming state of each module: "Toggle z2 arming state".

Arming and disarming has no effect until the z2-environment is synchronized - see next chapter.

h2. z2-sync

Clicking !z2_sync.png! in the toolbar or hitting <Alt+Y> triggers a z2-environment synchronization. 

z2 checks all(!) repositories for changes and applies them including your local dev-repository as 

well as any remote repository. This way your local changes are applied to your z2-instance. Also 

changes which have been committed in the meantime to SVN or Git repositories are applied. The set

of affected modules are displayed in the balloon notification.

h2. z2 dependency resolution

Clicking !z2_resolve_icon.png! in the toolbar or hitting <Alt+R> triggers a z2-dependency resolution which updates the

dependencies of all z2-modules in your IDEa and fixes all dangling references. 

Let's assume you have the z2-Modules A & B in your IDE where A depends on B and C (C is a z2-module which is not opened in the IDE, so it's called a remote module).

After the z2-refresh the dependencies of A will be fixed: If B is armed A will have a module reference to B

and a JAR-reference to C. C's JAR will be downloaded into a special folder called .z2env-lib. If B is not 

armed, A will have no module reference but two JAR references to B and C. 

Note that a z2-dependency resolution includes a z2-sync so that it also displays all affected modules when the operation is done.

h2. z2-Module wizard

h2. z2-Properties editor