The Servent is a piece of code written in Java, what means that a Java VM must be installed in order to run the Servent. The full Servent release will be decompressed in one directory ($HOME/servent by default). This directory can be deleted to unistall the Servent because there are no more dependencies outside this directory (no information is saved in any kind of registry or whatever).
The servent follows an strictly directories structure:
/-- servent/ |- bin/ |- lib/ |- common/ |- shared/ |- deploy/ \- servent.props
servent: | This is the rootPath where the servent is deployed. By default it is the $HOME/servent directory, but user can change it while installation. |
bin: | This directory contains some scripts useful for the servent. At the moment it contains the run.sh script (that runs the servent) and the client.sh script (that test one service deployed within the servent) |
lib: | Libraries directory. It contains different libraries that are useful to start the service but are specific of the Servent implementation. Services must not use none of these libraries |
common: | Libraries directory. It contains some common libraries that will normally used by all services |
shared: | Libraries directory. It contains specific libraries that will be loaded for each services, so services will all have a different copy of these libraries. |
deploy: | All services (DAR files) will be deployed here. |
servent.props | Configuration file for the servent |
Many operations related with the sevent startup use these directories and try to find it with the only acknowledge of the rootPath so, it is a bad idea to modify the name or the location of these directories. This can seem very restrictive but, in fact it is not. Maintaining this strict structure allow us to have less configuration (only rootPath is needed). By the way there is no reason for changing it.