For Developers ============== .. _jabaws_source: Source Code ----------- .. note:: This is an open source project. If you want to contribute or report an issue have a look at our `Git-tracker`_. Publicly available Git repository: http://source.jalview.org/gitweb/?p=jabaws.git .. code:: bash git clone http://source.jalview.org/git/jabaws.git ------------ .. _jabaws_api: The API ------- `Data Model JavaDoc`_ - read this if your are coding against JABA Web Services `Complete JavaDoc`_ - for developers who want to use JABAWS framework and use Engines and Executables directly ------------- .. _jabaws_structure: Structure of the project ------------------------ | |folder| *binaries* contains native executables e.g. clustalw | |folder| *src* contains sources of native executables | |folder| *windows* contains pre-compiled Windows binaries | |folder| *compilebin.sh* the script to complile binaries | |folder| *setexecflag.sh* the script to set executable flag for the binaries | |folder| *conf* contains JABAWS configuration files | |folder| *ExecutionStatistics* the database for storing collected execution statistics | |folder| *jobsout* a default folder for temporary job directories | |folder| *statpages* the web pages for execution statistics display | |folder| *WEB-INF* default | |folder| *website* contains the JABAWS web pages | |folder| *archive* contains JABAWS packages, the WAR and JAR files | |folder| *datamodel* contains the JABAWS datamodel | |folder| *engine* contains the JABAWS engine - the code that abstract the execution environment and executes native binaries | |folder| *runner* contains the JABAWS runners - thin wrappers for native binaries | |folder| *webservices* contains the JABAWS SOAP web services | |folder| *testsrc* contains the JABAWS unit tests ------------ .. _jabaws_code: The code structure ------------------ .. image:: ../../website/static/img/ws-structure.png :height: 414 :width: 282 :scale: 95 % :align: left Each source folder depends on the upper folders for compilation. For example, the datamodel is the top level folder so it has no other dependencies on other JABAWS code. The Engine level depends on the datamodel to compile etc. The web services folder is the bottom layer and depends on all the other source code. So the JABAWS project is split into 4 layers. From bottom-up the first layer consists from the value classes used by all other layers of the hierarchy, in particular web services. So, to be able to use JABAWS one needs to have these classes. At the same time classes on this layer does not have any dependencies on the layers above. The second layer contains code for execution of the wrappers, which are the abstraction describing native executables. JABAWS can execute tasks locally that is on the same machine as JVM and on the cluster. Thus currently code on this layer contain two engines. This layer depends on the layer underneath, the data model layer, but is completely independent from the code above. The third layer consists of the wrappers for the native executables and classes to handle their configuration. It depends on the engines and the data model, but know nothing about the web services. Finally, the upper layer contains the web services, that depend on all the layers below. The layer isolation is archived though specially designed compilation task which is executed sequentially in several stages so that the first layer compiles before any other layers, second layer compiles after that and process continies before all the code is compiled. Any violation of the layer boundaries results in the compilation failure. Use Ant "Compile" or "Complile_with_debug" tasks to perform the staged compilation. A client package contains only classes from data model layer and a simple web services client. Framework package is for anyone who want to use JABAWS framework for controlling native executables in local or cluster environments. Framework exclude the web services layer. Server package contains all the code. ------------ .. _jabaws_tests: Running tests ------------- JABAWS uses TestNG [test] framework for testing. The test results for the JABAWS package offered for download can be found at: Test Results [link] JABAWS uses TestNG for testing. There is a TestNG plugin available for Eclipse which has functionality similar to JUnit. However, no plugins are necessary to run the test cases, as testng jar is supplied with JABAWS together with an ant tasks to run the test cases. Several testing groups are supported: * All tests ('Test') * Cluster tests ('Run_cluster_dependent_test') * Cluster independent tests ('All_cluster_independent_tests') * Windows only tests ('All_cluster_independent_windows_only_tests') * Performance and stability tests ('Long_tests') * Re-run failed tests ('Rerun_failed_tests') * Run custom test ('CustomTest') To run the tests you need to download all sources from repository [link]. Once you have done that, enter into the command line mode, change directory to the project directory and type: .. code:: bash ant -f build.xml Make sure you have Apache Ant [link] installed and path to ant executable is defined in your path environmental variable. Replace test group name with the one of the names given in the list above to run required group of tests e.g for running cluster only tests use the following command: .. code:: bash ant -f build.xml Run_cluster_dependent_test If you work under Linux you could use a simple script from the root folder of repository called ``runtests.sh``. This script simply contains a collection of the test commands described above and paths to java home directory and an ant executable, which you can define once for your system and then reuse. A handy feature of TestNG is its ability to re-run failed tests. Failed test ant file is stored in ``test-output/testng-failed.xml``. and is used in the ant task called ``Rerun_failed_tests``. So re-running failed tests requires no more work than running any other test group and could be accomplished with the command: .. code:: bash ant -f build.xml Rerun_failed_tests CustomTest runs the test defined in the project root directory file called ``temp-testng-customsuite.xml``. This file is generated by TestNG plugin every time you run the test from Eclipse. Thus an easy way to run a test in a different environment is to run it from Eclipse first and then from ant using a custom test procedure. For cluster execution make sure that the property ``LD_LIBRARY_PATH`` defined in build.xml points to cluster engine LD libraries directory in your local system. ------------ .. _jabaws_conn_services: Accessing JABAWS from your program ---------------------------------- .. _jabaws_conn_functions: Web services functions overview ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All JABAWS multiple sequence alignment web services comply to the same interface, thus the function described below are available from all the services. Functions for initiating the alignment .. code:: bash String id = align(List list) String id = customAlign(List sequenceList, List