ANNOVAR module wrapping

We need someone who can wrap existing code as very simple, individual java objects in the open source SeqWare software pipeline. This requires only a small amount of Java code to wrap existing command line tools. ## Deliverables This job is to write a small Java wrappers for an existing command line tool, it will be approximately 1-2 hours of work just as has been done before (and will be done again). The details below may seem involved but the process is very simple once you have done one. There is potential for many more of these small jobs in the future. For a given module, the code source must be pre-compiled and statically linked to work with CentOs 5 and must also be wrapped in a way that exposes all the possible inputs as arguments. Here is where you can find the source code for the module we need wrapped up for this time: ANNOVAR [login to view URL] Instructions on how to wrap this application into a module can be found here: [[login to view URL]][1] Source code for the seqware project can be found here on the main page. [login to view URL] Finally, it is important that the module be documented fully. That means that the arguments that you can pass to it must be documented carefully so that others can make proper use of this module. You can see examples of documentation here: [[login to view URL]][2][w][2] Packaging details: All modules will be distributed as .zip files which will allow everyone to easily deploy them. Modules will have a very specific structure, along with an XML manifest to indicate which components are present. All modules need to have the following files and directories: manifest: This is a simple XML document that lists all the contents for the module The DTD for the manifest is as follows: <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT module (about,structure)> <!ELEMENT about (description,tag*,usage,params*)> <!ELEMENT description ANY> <!ELEMENT tag (#PCDATA)> <!ELEMENT usage ANY> <!ELEMENT param (flagName,flagValue)> <!ELEMENT flagName (#PCDATA)> <!ELEMENT flagValue ANY> <!ELEMENT structure (tests,wrapper,bin,script*,src*)> <!ELEMENT tests (test*,data*,output*)> <!ELEMENT test (#PCDATA)> <!ELEMENT data (#PCDATA)> <!ELEMENT output (#PCDATA)> <!ELEMENT wrapper (#PCDATA)> <!ELEMENT bin (#PCDATA)> <!ELEMENT script (perl*, python*)> <!ELEMENT perl (#PCDATA)> <!ELEMENT python (#PCDATA)> <!ELEMENT src (#PCDATA)> Basically, each element of the DTD needs to include the relevant information. You just need to fill out the xml elements as if you were filling out a form to indicate which elements of the module are present. An example of how this might look is below: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE module SYSTEM "[login to view URL]"> <module> <about> <description>SNVMix is a module for making SNV calls. It is an especially good algorithm to use when looking at cancer samples as they frequently have gross duplications of large portions of the genome</description> <tag>SNV</tag> <tag>cancer</tag> <tag>SNP</tag> <usage>./bin/[login to view URL] --no-metadata -module [login to view URL] -- -script /path/seqware/trunk/seqware-pipeline/bin/SNVMix2 -i /path/[login to view URL] -m /path/SNVMix2-0.11.8-r3/[login to view URL] -C -p s -t M </usage> <params> <flagDescr>get help</flagDescr> <flagValue>--help</flagValue> </params> </about> <structure> <tests> <data> [login to view URL] </data> <data> [login to view URL] </data> </tests> <wrapper> [login to view URL] </wrapper> <bin> SNVMix2 </bin> <script> <perl>[login to view URL] </perl> <perl>[login to view URL] </perl> <perl>[login to view URL] </perl> </script> <src> the source code for SNVMix </src> </structure> </module> README: It is expected that a README will be present here which will detail not only what the module is meant to be used for (with references), but which will also give a usage example that should run with the package installed and it's included test files. Individual READMEs that come from the sources (and that go with the various source files are expected to be packaged along with the individual source files in the src directory. tests: The idea for the tests directory is that these will be like unit tests for each module except that unlike full unit tests these tests just verify that the entire module can produce a desired output when run. The tests directory has the following subdirectories tests/script - used to store test scripts (shell scripts). There can be more than one if this is helpful, but I expect that normally this will be a single one liner script. When called the script should execute the module code on the data files and end by diffing the output against a specific target located in tests/output tests/data - used to store small data files (<20 mb) for running the tests. If a file is too large, then a file should be included here that designates an online resource. tests/output - used to store the output expected from running the tests. If normally sent to standard out, then this should be able to be captured and diffed. java: Used for the .java files (wrappers for modules) bin: Used for compiled binaries Some modules may also need to have the following directories: script: Used for storing scripts that are needed by the module to run. scripts can have the folowing subdirs. script/perl - used to store perl scripts script/python - used for python scripts src: Used for storing the src files and make files etc. that are needed to compile the package binaries.