/htsjdk

A Java API for high-throughput sequencing data (HTS) formats.

Primary LanguageJava

Coverage Status Build Status Maven Central License Language Join the chat at https://gitter.im/samtools/htsjdk

Status of downstream projects automatically built on top of the current htsjdk master branch. See gatk-jenkins for detailed logs. Failure may indicate problems in htsjdk, but may also be due to expected incompatibilities between versions, or unrelated failures in downstream projects.

A Java API for high-throughput sequencing data (HTS) formats.

HTSJDK is an implementation of a unified Java library for accessing common file formats, such as SAM and VCF, used for high-throughput sequencing data. There are also an number of useful utilities for manipulating HTS data.

NOTE: HTSJDK does not currently support the latest Variant Call Format Specification (VCFv4.3 and BCFv2.2).

Documentation & Getting Help

API documentation for all versions of HTSJDK since 1.128 are available through javadoc.io.

If you believe you have found a bug or have an issue with the library please a) search the open and recently closed issues to ensure it has not already been reported, then b) log an issue.

The project has a gitter chat room if you would like to chat with the developers and others involved in the project.

To receive announcements of releases and other significant project news please subscribe to the htsjdk-announce google group.

Building HTSJDK

HTSJDK is now built using gradle.

A wrapper script (gradlew) is included which will download the appropriate version of gradle on the first invocation.

Example gradle usage from the htsjdk root directory:

  • compile and build a jar
./gradlew

or

./gradlew jar

The jar will be in build/libs/htsjdk-<version>.jar where version is based on the current git commit.

  • run tests, a specific test class, or run a test and wait for the debugger to connect
./gradlew test

./gradlew test -Dtest.single=TestClassName

./gradlew test --tests htsjdk.variant.variantcontext.AlleleUnitTest
./gradlew test --tests "*AlleleUnitTest"

./gradlew test --tests "*AlleleUnitTest" --debug-jvm
  • run tests and collect coverage information (report will be in build/reports/jacoco/test/html/index.html)
./gradlew jacocoTestReport
  • clean the project directory
./gradlew clean
  • build a monolithic jar that includes all of htsjdk's dependencies
./gradlew shadowJar
  • create a snapshot and install it into your local maven repository
./gradlew install
  • for an exhaustive list of all available targets
./gradlew tasks

Create an HTSJDK project in IntelliJ

To create a project in IntelliJ IDE for htsjdk do the following:

  1. Select fom the menu: File -> New -> Project from Existing Sources
  2. In the resulting dialog, chose Import from existing model, select Gradle and Next
  3. Choose the default gradle wrapper and Finish.

From time to time if dependencies change in htsjdk you may need to refresh the project from the View -> Gradle menu.

Licensing Information

Not all sub-packages of htsjdk are subject to the same license, so a license notice is included in each source file or sub-package as appropriate. Please check the relevant license notice whenever you start working with a part of htsjdk that you have not previously worked with to avoid any surprises. Broadly speaking the majority of the code is covered under the MIT license with the following notable exceptions:

  • Much of the CRAM code is under the Apache License, Version 2
  • Core tribble code (underlying VCF reading/writing amongst other things) is under LGPL
  • Code supporting the reading/writing of SRA format is uncopyrighted & public domain

Java Minimum Version Support Policy

We will support all Java SE versions supported by Oracle until at least six months after Oracle's Public Updates period has ended (see this link).

Java SE Major Release End of Java SE Oracle Public Updates Proposed End of Support in HTSJDK Actual End of Support in HTSJDK
6 Feb 2013 Aug 2013 Oct 2015
7 Apr 2015 Oct 2015 Oct 2015
8 Jul 2018 Jul 2018 TBD

HTSJDK is migrating to semantic versioning (http://semver.org/). We will eventually adhere to it strictly and bump our major version whenever there are breaking changes to our API, but until we more clearly define what constitutes our official API, clients should assume that every release potentially contains at least minor changes to public methods.