ANNOVAR module wrapping(repost)

Dibatalkan Dipasang Mar 6, 2011 Dibayar saat pengiriman
Dibatalkan Dibayar saat pengiriman

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

[url removed, login to view]

Instructions on how to wrap this application into a module can be found here:

[[url removed, login to view]][1]

Source code for the seqware project can be found here on the main page.

[url removed, login to view]

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:

[[url removed, login to view]][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 "[url removed, login to view]">

<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/[url removed, login to view] --no-metadata -module [url removed, login to view] -- -script /path/seqware/trunk/seqware-pipeline/bin/SNVMix2 -i /path/[url removed, login to view] -m /path/SNVMix2-0.11.8-r3/[url removed, login to view] -C -p s -t M </usage>

<params>

<flagDescr>get help</flagDescr>

<flagValue>--help</flagValue>

</params>

</about>

<structure>

<tests>

<data> [url removed, login to view] </data>

<data> [url removed, login to view] </data>

</tests> <wrapper> [url removed, login to view] </wrapper>

<bin> SNVMix2 </bin>

<script>

<perl>[url removed, login to view] </perl>

<perl>[url removed, login to view] </perl>

<perl>[url removed, login to view] </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.

Java Linux Perancangan Perangkat Lunak

ID Proyek: #3149769

Tentang proyek

1 proposal Proyek online Aktif Apr 4, 2011

1 freelancer menawar dengan rata-rata $64 untuk pekerjaan ini

ragastens

See private message.

$63.75 USD dalam 14 hari
(32 Ulasan)
4.3