Step 3 - First steps with Z2 on Git » History » Revision 63

Revision 62 (Henning Blohm, 16.09.2018 21:27) → Revision 63/68 (Henning Blohm, 16.09.2018 21:36)

h1. First steps with Z2 on Git 

 [[Step_2_-_Install_and_run_in_5_minutes|« Step 2 - Install and run in 5 minutes]] 

 h2. Prerequisites 

 You need a z2-base installation as described on the [[How_to_install_z2_v21|previous]] page. 
 Furthermore you need the "Eclipse-IDE": (one of Galileo, Helios, Indigo, Juno or Kepler is fine) and the "Egit plug-in:":  

 h2. First steps with the z2-Environment 

 Next, we will look at development for Z2 with Git using Eclipse. Please stop the server before you continue. 

 In order to have module modifications from locally cloned repositories discovered by Z2, it is required for the repositories and workspace to be siblings to each other. Go back to the "z2-base" directory (@cd ../..@, if you are inside the "bin" directory) and create a folder called "workspace" - this will be used as the workspace root for Eclipse: 

 :bin$ cd ../.. 
 :z2-base$ mkdir workspace 
 :z2-base$ ls -l 
 total 0 
 0 drwxr-xr-x     2 mr_x    staff     68    7 Sep 16:34 workspace 
 0 drwxr-xr-x    12 mr_x    staff    408    7 Sep 15:11 z2-base.core 

 Now start Eclipse and choose @z2-base/workspace@ as your workspace folder. 

 For convenience, we recommend to create an "External Tool Configurations" to start the Z2 Graphical User Interface (GUI) from within your development environment. Add the start script (or @gui.bat@ on Windows) from the z2-base.core/bin folder as the "Main Location". 

 When running you should see a new window labeled "Z2 Home (z2-base)": 


 The z2-Environment provides an Eclipse plug-in called "Eclipsoid" that has a lot of neat utilities and one really important feature: Dependency resolution from a running z2-Environment. 

 Here's the catch: When developing with Eclipse, projects in your workspace may require Java types from other projects to compile. Eclipse will try to verify that, every time you save a source code modification. When working on a non-trivial system, you may have a lot of dependencies that you will typically not want to see clutter your workspace. That is where the plugin comes into the game. This way you can checkout and focus on a project subsets while the Eclipsoid plug-in provides the transitive closure of all required prjects and libraries.  

 Other features provided by the Eclipsoid plug-in that are explained in more details on the [[Eclipsoid]] wiki pages. 

 {{include(how to install eclipsoid)}} 

 h2. Changing source code and check the result 

 To change source code, we need a project in Eclipse. Let's change the simple calculator Web application that is contained in the z2-base.base repository.  

 To do so, we want to  

 # Make the Git repository available in Eclipse's Git tool EGit,  
 # Import the project into Eclipse and  
 # Change the project and check the result. 

 For the first step, open Eclipse's Git perspective and clone the repository at 

 Make sure it is cloned next to the workspace folder and the z2-base.core folders we created previously. This is because - by default - Z2 is configured to discover changes in locations next to the z2-Home, i.e. the z2-base.core folder. 

 To import the project want to work on into your workspace, import the "com.zfabrik.samples.calculator" from the z2-base.base repository in the Git perspective. 

 Once the project is imported go to the Java Package Explorer view and drill down to +/com.zfabrik.samples.calculator/java/src.impl/com/zfabrik/samples/calculator/impl/, open the the class via double click. The result should look like this: 


 You will find that the source code is marked with colored squiggles and red x-markers indicating that Eclipse's compiler is not able to resolve certain identifiers. If you want you can check the classpath of the project and indeed there are only three entries: One for the JRE, one for the sources, and one called "Eclipsoid: z2-Environment Build Container". This container will resolve the incomplete class-path when it is asked to do so. Click the toolbar icon !z2_resolve_icon.png! or hit <Alt+R> to trigger a refresh of that build container from your locally running Z2. All red x-markers should be gone by now.  

 Before we change the code let's have a look at the current state. Launch http://localhost:8080/calc and play around with the calculator. You might miss some operations like logarithm or square root which we are going to add now. Go back to Eclipse and the Calculator class. Uncomment one line inside the enum OP definition: 

 <pre><code class="java"> 
 private enum OP { 
	 CE, C, open, close,  
	 sqrt, pow, ln, epowx, 
	 sgn, dot, eq, pi,  
	 add, sub, mult, div,  
	 sqr, inv, illegal 

 Scroll down to method @doOp()@ and uncomment the section from @case sqrt:@ to @case epowx:@ (line 154 to 170): 

 <pre><code class="Java"> 

 case sqrt: 
	 new Sqrt().addTo(this.stack); 
 case pow: 
	 new Pow().addTo(this.stack); 

 case ln: 
	 new Ln().addTo(this.stack); 
 case epowx: 
	 new EPowX().addTo(this.stack); 

 The implementation classes of these operations do are already exists.  
 We must also add the operations to the visual layout which is implemented as a JSP file. Navigate to +/com.zfabrik.samples.calculator/web/WebContent/calc.jsp+ and open the file. Scroll down to line 102 and uncomment the block annotated with "uncomment me": 

 <pre><code class="html"> 
 <button type="submit" name="op=CE" title="C">CE</button> 
 <button type="submit" name="op=sqrt" title="r">&radic;</button> 
 <button type="submit" name="op=pow" title="^">x<sup>y</sup></button> 
 <button type="submit" name="op=ln" title="l">ln</button> 
 <button type="submit" name="op=epowx" title="e">e<sup>x</sup></button> 
 <button type="submit" name="op=pi" title="p">&pi;</button> 

 Now what happens next is really important to understanding the principles behind Z2. In order to test our modification we will not deploy any kind of archive. Instead we will make sure it considers the project in our workspace a preferred version of the calculator project.  

 From the Z2 point of view the Eclipse workspace is yet another component repository. We call the implementation the _Dev-Repository_. 

 Z2 will not consider any arbitrary file system structure noteworthy. Instead to make the inclusion of a specific project into the Dev-Repository effective, we will _arm_ it. This is so that you can choose whether a local workspace version of a module should be considered or rather not. Practically, arming means nothing more elaborate but to put a file called *LOCAL* into the project folder. 

 When we ask the Z2 server to check for new changes (we say "to _synchronize_ the server"), it will find two versions of our calculator project: one inside the *z2-base.base* repository and one inside the Dev-repository (i.e. your workspace). Because of the preference rule above, the version in your workspace will be considered with preference. 

 To "arm" the calculator project right-click the project "com.zfabrik.samples.calculator" in the Java Package Explorer and choose "Arm z2-Projects" (which, a indicated, does in fact nothing but putting an empty LOCAL file). 

 You will see a green "z" decoration at the upper left edge of the Java icon in the package explorer: !green_z_decoration.png!. 

 After we specified that the workspace version of the calculator project should win over the one in the Git repository we can trigger the z2 synchronization: Choose "Sync with z2-environment" from the "z2-environment" menu, click the new z-icon !z2_sync.png! or hit <Alt+Y>.  

 The connection with the Z2 server is established via he Eclipsoid plug-in over http. In situations where the Web server cannot be started, the Eclipsoid web application will not be available. In this case the z2-gui is the only way to trigger a synchronization (except of a shutdown and restart). You will also see that the log-messages in the z2-gui log pane has changed and that the server has invalidated and restarted one resource: 

 09/28 13:14:47 [36]...entRepositoryImpl [800]: Pulled deltas within 874msec from GitCR com.zfabrik.boot.config/baseRepository (origin=, branch=v2.1, OPTIONAL, root=/Users/udoo/dev/temp/z2-base/z2-base.core/run/bin/../../work/repos/95f655a0/git) 
 09/28 13:14:47 [36]...hronizationRunner [800]: Found 2 invalidation candidate resources 
 09/28 13:14:47 [36]...hronizationRunner [800]: Invalidated 0 resources 
 09/28 13:14:47 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:47 [19]...stemStateResource [800]: Left system state: environment/webWorkerUp 
 09/28 13:14:47 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:47 [19]...pp.WebAppResource [800]: Stopping Web App (/calc): com.zfabrik.samples.calculator/web 
 09/28 13:14:47 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:47 [19]...worker.WorkerSoul [800]: Invalidated 2 resources 
 09/28 13:14:47 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:47 [19]...pp.WebAppResource [800]: Starting WebApp: com.zfabrik.samples.calculator/web 
 09/28 13:14:48 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:48 [19]...pp.WebAppResource [800]: Done starting Web App (/calc): com.zfabrik.samples.calculator/web 
 09/28 13:14:48 [33]...ent/webWorker@0.2 [800]: 09/28 13:14:48 [19]...stemStateResource [800]: System state attained: environment/webWorkerUp 
 09/28 13:14:48 [36]...mponentRepository [800]: Overriding module com.zfabrik.samples.calculator: 

 Now it's time to check the result: http://localhost:8080/calc - voilà!  

 You should repeat these steps a few times: Change the source code (e.g. adding more new calculator operations like sine, cosine, tangent...), hit <Alt+Y> and check the result, so you will get a feeling of how fast development round trips can be! 

 h2. Commit and Share 

 Once you have finished, you would normally commit and push your changes. Using the z2-base.base repository that is not such a good idea however. 

 But let's assume it was your repository. How would things work from here on, assuming you actually had committed and pushed.  

 In a real-world scenario, your repositories would typically not be local but may be shared with other developers working on the same system. Even if you preferred to have them locally on your development machine, they would not be _in_ your Z2 installation. 

 In fact, you would configure additional repositories to be accessed from Z2. After commit and push you could disarm (remove LOCAL) from your local workspace module and at the next synchronization, Z2 would discover the update from the remote repository.  

 Development with Z2 means: 

 * Unless you arm local copies of modules, your system is automatically up-to-date with remote sources. 
 * In local repository clones, arm modules you are working on. Modify until satisfied with your changes, 
 * Check frequently by synchronizing and testing, 
 * Commit, push, disarm, synchronize, 
 * Repeat. 

 The configuration of further repositories is discussed in [[How_to_create_your_own_system]] and the reference documentation (see below). 

 h2. What's next? 

 Please visit the [[Samples]]. In most cases, trying them is straight-forward and instructive. 

 Want to understand it better? There are some more detailed articles in this wiki. However, for a structured reference and introduction, you are strongly encouraged to start reading the documentation in parallel to any other investigation either via the samples or the howtos: 

 * Start reading the "v2.6 documentation": 
 * Check out some of the blogs at [[wiki#blogs|Blogs]]