The Dependency Graph for the full installation of OpenGTS 2.4.3 (through 2.4.7) looks pretty complex at first sight and may be confusing for an understanding of the core system structure. From the previous analysis we know that OpenGTS comes with a number of Device Communication Servers, which can be grouped into identical structures.
Basically there are two groups of DCSs:
- http DC Servers running inside Tomcat
- tcp / udp DC Servers running in the plain Java JVM
Considering this the build.xml file can be reduced to one DCS for each network protocol, plus the template DCS for later implementations for a Tracker of your choice. The original build file is also prepared to install resources not included in the basic Open Source Distribution.
Creating your own Lite Version
For a later integration of ROAF Components into OpenGTS the reduction of OpenGTS to a core suited for ROAF Development is a useful exercise. This example should only outline the process of the reduction. For the expected updates of OpenGTS you should follow the process instead of using the resulting Lite Version at the end of this page.
The starting point is the existing installation of the original OpenGTS_2.4.3 through 2.5. The database (structure) is not necessary, but useful, preferably with existing Accounts, Users, Events and other data. The checkInstall skript should run without warnings and errors.
First you should open a shell or console and
- run: C:\prox\OpenGTS_2.4.3> ant all
- copy build.xml to buildLite.xml
- run: C:\prox\OpenGTS_2.4.3> ant -buildfile buildLite.xml all
Then you can start reducing the buildLite.xml file to a desired minimum GTS system with the components you want to use or modify. A major constraint for this minimum build file is that it can replace the original build file in the OpenGTS release. Both files delete and re/create the build folder, but you are free to create the full build folder, add an extension like build.org, rerun the minimum build and rename the folder to build.min, for example.
The buildLite.xml file created from OpenGTS_2.4.3 and tested up to 2.5 was reduced by removing the following elements:
- org.opengts.extra... packages like
- optional="true" targets like
<import file="build_rulewar.xml" optional="true"/>
- <!-- ok if this file does not exist --> targets like
- external libraries like
since they are already part of the pre/installation process
- dependency to build_custom.xml file
- <!-- copy "dcservers/dcserver_*" files (may not be present) -->
- various jar files, which are not part of the core OpenGTS distribution
-> dmtpserv, audit, custom, customtrack, opttrack, optdb, ruledb, bcrossdb
Due to the complex dependencies you should run 'ant -buildfile buildLite.xml all' after every removal. The buildLite.xml file provided in the OpenGTS_2.4.3.Lite.zip download below has about half the size ( 1153 / 2205 lines) of the original. You can also download the buildLite.xml file (buildLite.120902.xml) and use it for OpenGTS versions 2.4.3 to 2.4.7 here:
Now the dependency graph (in 'bus' representation) provides a much better overview of the GTS:
Additionally the buildLite.xml file removes all TCP DC Servers exept tk10x and template and all http DCS exept gc101 and gprms. You should pick your own 'reference DCS' and consider buying them for reference tracking.
As a first step you might want to draw the buildLite.xml file from the archive, move it to your OpenGTS_2.4.x installation and apply it to create a leaner build folder than the original. The archive itself goes a step further. OpenGTS_2.4.3.Lite.zip was originally a copy of OpenGTS_2.4.3.zip and additionally the resources not included in the build process were removed:
remove java source folders
remove war sources and resources
Remember that this is only an example and you could go further by removing all the dmtp stuff, which is indicated in the creation of the gtsdb.jar with
<!-- compile GTS db -->
<!-- Misc -->
For this roaf.de/opengts/ section the archive (tested up to 2.4.7)
will simplify the following analysis and it may help you to create your version. Later, when planing and beginning the ROAF implementation this setup can serve as a good starting point to integrate additional re/sources and modules. By comparing the minimized to the original build.xml file the developer has the choice to add modules (with a practical diff tool) as needed. And he can choose to work in a bottom up mode to create his own build file.
|« ant build||web apps »|