5.1 Generating the System
5.1.1 How To Generate
|
The generation of the GigaSpaces System is driven from the model (this is model driven development after all!) To generate a system:
Select the model - this must be a '.osm' file, and it should be the only '.osm' file in the project - which you wish to generate ->
Right Click -> GigaSpaces Build -> All
This will kick off an Ant task which should be visible in the console. The Ant task will first convert the model (the .osm) into
a native JeeWiz format. JeeWiz will then take this and generate a set of eclipse projects based on what is defined in the model.
Although there are two other targets in the Ant task ('Convert' and 'Build') that you could use, it is recommended that you use 'All'.
The 'Convert' target merely converts the .osm into native JeeWiz format (the .osm.converted) file.
The 'Build' target uses the .osm.converted file to build the system.
When you run a build, GigaSystemBuilder automatically saves the file if it has changed.
Furthermore, it may also rewrite the model to add unique IDs (to enable it to keep track of business logic that must be preserved across builds).
This rewriting should have no impact on your model.
5.1.2 Fixing Errors
|
Errors in the build process appear in the log file if you have ticked "Create in the
Generate-Time Preferences,
and on the "Console" window in Eclipse if you have not.
The initial error report from Ant, if you have not disabled it, will looks like this:
This is not useful for debugging the problem - you need to look at the console output or log file.
You need to find the last error reprot from the generation system, which will look like this
Error processing template file C:\jeewiz\resources\...\preIncludeSpec.vm
Message: Name is required for <application 'TheApplication'>
reported by model object <application 'TheApplication'>
Velocity template stack:
[0] C:\jeewiz\resources\giga-spaces\control\application\preIncludeSpec.vm
Original call to fatal from
C:\jeewiz\resources...\preIncludeSpec.vm [line 5, column 7]
|
5.1.3 What is Generated
|
Additional Eclipse Projects
When a system is generated it will resut in a number of additional eclipse projects being generated and if you are generating
from within eclipse, they will be added automatically to the workspace,
A new eclipse java project will be created for every modelled Processing Unit and Jar. The naming convention for these additional projects is
<ApplicationName>_<ProcessingUnit>Name
<ApplicationName>_<Jar>Name
|
Two additional projects are generated. The first is the common jar. It holds all the helper classes, java beans, service interfaces.
The second is the Utility Processing Unit which provides the logging service, the registration service and the additional processing service.
<ApplicationName>_GSBFramework
<ApplicationName>_UtilityPU
|
The structure of these generated projects will be identical and will contain:
- A build.xml This is used to build the project from outside of eclipse
- A source tree. This contains all the regenerated artefacts. By default the top level of this tree is 'src'.
- A business logic tree. This is where the developer adds the business logic. By default the top level of this tree is 'impl'.
The Source Tree - 'src'
The source tree holds all the code and artefacts that will be regenerated each build. Therefore the developer should not add any of their
own code into this area.
The generated artefacts in the source tree will vary depending on what has been modelled, but will include any beans, helper classes and in the
case of a Processing Unit the pu.xml.
Helper Classes
Helper classes are always generated into the source tree, though in some cases they be only in the least dependant jar or processing unit project.
| What is generated |
Name |
Description |
| JeeWizUtils Class |
JeeWizUtils.java |
This is generated in the least dependant processing unit or jar. JeeWizUtils.java contains a large number of useful data manipulation methods. |
| Service Interface
| I<ServiceName>.java |
This is one interface per service in the whole system. All interfaces are generated into the least dependant processing unit or jar. |
| A Space Finder Class |
<ProcessingUnitPackage>.GsbSpaces.java |
This contains a reference to all the spaces used by this Processing Unit. This is the equivalent of the @GigaSpaceContext. |
The Implementation Tree - 'impl'
The implementation tree is where the developer adds the business logic. See Adding Business Logic for more details
on how to add business logic.
Again the generated artefacts in the implementation tree will vary and depend on what has been modelled. Below is a list of the implementation
classes that may be generated
| What is generated |
Name |
Description |
| An Action Class |
<ProcessingUnitName>_Actions.java |
There is one action class per processing unit and one method per action in the action class. |
| A LifecycleEventClass |
<SpaceName>LifecycleEvent.java |
There is one lifcycleEvent class per space unit and one method per lifecycle event. |
| A Service Class |
ServiceName>.java |
There is one service class per service and one method per modelled business-method. |
DVLA Processing Unit Example
Below is a screen shot of the generated java project for the DVLA Processing Unit from the CongestionChargeApp application used in
the tutorial.
In this case the DVLA Processing Unit had a single service modelled. So in the generated 'src' tree there is the GsbSpaces.java helper class.
In the 'impl' tree there is the implementation class of the service (LicenceService.java)
It is within this class that the business logic is added to implement the service.
5.1.4 Regenerating
|
The model can be amended at any time and the system regenerated. Any implementation code added by the developer in the appropriate
places will remain unchanged. The process for regenerating is the same as the for generating. See the 'How To Generate' for details.
| 
