mvn -Ddisable.shadepackage verify
In addition to Queue's GATK-wrapper codegen, relatively slow scala compilation, etc. there's still a lot of legacy compatibility from our
ant days in the Maven scripts. Our
mvn verify behaves more like when one runs
ant, and builds everything needed to bundle the GATK.
As of GATK 3.4, by default the build for the "protected" code generates jar files that contains every class needed for running, one for the GATK and one for Queue. This is done by the Maven shade plugin, and are each called the "package jar". But, there's a way to generate a jar file that only contains
META-INF/MANIFEST.MF pointers to the dependency jar files, instead of zipping/shading them up. These are each the "executable jar", and FYI are always generated as it takes seconds, not minutes.
While developing and recompiling Queue, disable the shaded jar with
-Ddisable.shadepackage. Then run
java -jar target/executable/Queue.jar ... If you need to transfer this jar to another machine / directory, you can't copy (or rsync) just the jar, you'll need the entire executable directory.
# Total expected time, on a local disk, with Queue: # ~5.0 min from clean # ~1.5 min per recompile mvn -Ddisable.shadepackage verify # always available java -jar target/executable/Queue.jar --help # not found when shade disabled java -jar target/package/Queue.jar --help
If one is only developing for the GATK, skip Queue by adding
mvn -Ddisable.shadepackage -P\!queue verify # always available java -jar target/executable/GenomeAnalysisTK.jar --help # not found when queue profile disabled java -jar target/executable/Queue.jar --help
The GATK 3.2 source code uses new java package names, directory paths, and executable jars. Post GATK 3.2, any patches submitted via pull requests should also include classes moved to the appropriate artifact.
Note that the document includes references to the
private module, which is part of our internal development codebase but is not available to the general public.
A long term ideal of the GATK is to separate out reusable parts and eventually make them available as compiled libraries via centralized binary repositories. Ahead of publishing a number of steps must be completed. One of the larger steps has been completed for GATK 3.2, where the code base rebranded all references of Sting to GATK.
Currently implemented changes include:
As of May 16, 2014, remaining TODOs ahead of publishing to central include:
Now that the new package names and Maven artifacts are available, any pull request should include ensuring that updated classes are also moved into the correct GATK Maven artifact. While there are a significant number of classes, cleaning up as we go along will allow the larger task to be completed in a distributed fashion.
The full lists of new Maven artifacts and renamed packages are below under [Renamed Artifact Directories]. For those developers in the middle of a
git rebase around commits before and after 3.2, here is an abridged mapping of renamed directories for those trying to locate files:
|Old Maven Artifact||New Maven Artifact|
QScripts are no longer located with the Queue engine, and instead are now located with the GATK wrappers implemented as Queue extensions. See [Separated Queue Extensions] for more info.
Starting with GATK 3.2, separate Maven utility artifacts exist to separate reusable portions of the GATK engine apart from tool specific implementations. The biggest impact this will have on developers is the separation of the walkers packages.
In GATK versions <= 3.1 there was one package for both the base classes and the implementations of walkers:
In GATK versions >= 3.2 threre are two packages. The first contains the base interfaces, annotations, etc. The latter package is for the concrete tools implemented as walkers:
Previously, depending on how the source code was compiled, the executable gatk-package-3.1.jar and queue-package-3.1.jar (aka GenomeAnalysisTK.jar and Queue.jar) contained various mixes of public/protected/private code. For example, if the private directory was present when the source code was compiled, the same artifact named gatk-package-3.1.jar might, or might not contain private code.
Starting with 3.2, there are two versions of the jar created, each with specific file contents.
|New Maven Artifact||Alias in the /target folder||Packaged contents|
When creating a packaged version of Queue, the GATKExtensionsGenerator builds Queue engine compatible command line wrappers around each GATK walker. Previously, the wrappers were generated during the compilation of the Queue framework. Similar to the binary packages, depending on who built the source code, queue-framework-3.1.jar would contain various mixes of public/protected/private wrappers.
Starting with GATK 3.2, the gatk-queue-3.2.jar only contains code for the Queue engine. Generated and manually created extensions for wrapping any other command line programs are all included in separate artifacts. Due to a current limitation regarding how the generator uses reflection, the generator cannot build wrappers for just private classes without also generating protected and public classes. Thus, there are three different Maven artifacts generated, that contain different mixes of public, protected and private wrappers.
|Extensions Artifact||Generated wrappers for GATK tools|
As for QScripts that used to be located with the framework, they are now located with the generated wrappers.
|Old QScripts Artifact Directory||New QScripts Artifact Directory|
The following list shows the mapping of artifact names pre and post GATK 3.2. In addition to the engine changes, the packaging updates and extensions changes above also affected Maven artifact refactoring. The packaging artifacts have split from a single public to protected and private versions, and new queue extensions artifacts have been added as well.
|Maven Artifact <= GATK 3.1||Maven Artifact >= GATK 3.2|
A note regarding the aggregator:
The aggregator is the pom.xml in the top directory level of the GATK source code. When someone clones the GATK source code and runs
mvn in the top level directory, the aggregator the pom.xml executed.
The root is a pom.xml that contains all common Maven configuration. There are a couple dependent pom.xml files that inherit configuration from the root, but are NOT aggregated during normal source compilation.
As of GATK 3.2, these un-aggregated child artifacts are VectorPairHMM and picard-maven. They should not run by default with each instance of
mvn run on the GATK source code.
For more clarification on Maven Inheritance vs. Aggregation, see the Maven introduction to the pom.
In GATK 3.2, except for classes with Sting in the name, all file names are still the same. To locate migrated files under new java package names, developers should either use Intellij IDEA Navigation or
/bin/find to locate the same file they used previously.
The biggest change most developers will face is the new package names for GATK classes. Code entanglement does not permit simply moving the classes into the correct Maven artifacts, as a few number of lines of code must be edited inside a large number of files. So post renaming only a very small number of classes were moved out of the incorrect Maven artifacts as examples.
As of the May 16, 2014, the migrated GATK package distribution is as follows. This list includes only main classes. The table excludes all tests, renamed files such as StingException, certain private Queue wrappers, and qscripts renamed to end in *.scala.
|Scope||Type||<= 3.1 Artifact||<= 3.1 Package||>= GATK 3.2 Artifact||>= 3.2 GATK Package||Files|
During all future code modifications and pull requests, classes should be refactored to correct artifacts and package as follows.
All non-engine tools should be in the tools artifacts, with appropriate sub-package names.
The following class names were updated to replace Sting with GATK.
|Old Sting class||New GATK class|
The 3.2 renaming patch is actually split into two commits. The first commit renames the files without making any content changes, while the second changes the contents of the files without changing any file paths.
When dealing with renamed files, it is best to work with a clean directory during rebasing. It will be easier for you track files that you may not have added to git.
After running a git rebase or merge, you may first run into problems with files that you renamed and were moved during the GATK 3.2 package renaming. As a general rule, the renaming only changes directory names. The exception to this rule are classes such as StingException that are renamed to GATKException, and are listed under [Renamed Classes]. The workflow for resolving these merge issues is to find the list of your renamed files, put your content in the correct location, then register the changes with git.
To obtain the list of renamed directories and files:
git statusto get a list of affected files
Then, to resolve the issue for each file:
git rmthe old paths as appropriate
git addthe new path
Upon first rebasing you will see a lot of text. At this moment, you can ignore most of it, and use git status instead.
For the purposes of illustration, while running
git rebase it is perfectly normal to see something similar to:
$ git rebase master First, rewinding head to replay your work on top of it... Applying: <<< Your first commit message here >>> Using index info to reconstruct a base tree... A protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngine.java A protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngineUnitTest.java <<<Other files that you renamed.>>> warning: squelched 12 whitespace errors warning: 34 lines add whitespace errors. Falling back to patching base and 3-way merge... CONFLICT (rename/rename): Rename "protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngineUnitTest.java"->"protected/gatk-tools-protected/src/test/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngineUnitTest.java" in branch "HEAD" rename "protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngineUnitTest.java"->"protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/HaplotypeCallerGenotypingEngineUnitTest.java" in "<<< Your first commit message here >>>" CONFLICT (rename/rename): Rename "protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngine.java"->"protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngine.java" in branch "HEAD" rename "protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngine.java"->"protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/HaplotypeCallerGenotypingEngine.java" in "<<< Your first commit message here >>>" Failed to merge in the changes. Patch failed at 0001 Example conflict. The copy of the patch that failed is found in: /Users/zzuser/src/gsa-unstable/.git/rebase-apply/patch When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". $
While everything you need to resolve the issue is technically in the message above, it may be much easier to track what's going on using
$ git status rebase in progress; onto cba4321 You are currently rebasing branch 'zz_renaming_haplotypecallergenotypingengine' on 'cba4321'. (fix conflicts and then run "git rebase --continue") (use "git rebase --skip" to skip this patch) (use "git rebase --abort" to check out the original branch) Unmerged paths: (use "git reset HEAD <file>..." to unstage) (use "git add/rm <file>..." as appropriate to mark resolution) added by them: protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/HaplotypeCallerGenotypingEngine.java both deleted: protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngine.java added by them: protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/HaplotypeCallerGenotypingEngineUnitTest.java both deleted: protected/gatk-protected/src/test/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngineUnitTest.java added by us: protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngine.java added by us: protected/gatk-tools-protected/src/test/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngineUnitTest.java Untracked files: (use "git add <file>..." to include in what will be committed) <<< possible untracked files if your working directory is not clean>>> no changes added to commit (use "git add" and/or "git commit -a") $
Let's look at the main java file as an example. If you are having issues figuring out the new directory and new file name, they are all listed in the output.
Path in the common ancestor branch: | old source directory | old package name | old file name | protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/GenotypingEngine.java Path in the new master branch before merge: | new source directory | new package name | old file name | protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngine.java Path in your branch before merge: | old source directory | old package name | new file name | protected/gatk-protected/src/main/java/org/broadinstitute/sting/gatk/walkers/haplotypecaller/HaplotypeCallerGenotypingEngine.java Path in your branch post merge: | new source directory | new package name | new file name | protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/HaplotypeCallerGenotypingEngine.java
After identifying the new paths for use post merge, use the following workflow for each file:
git rmthe three old file paths: common ancestor, old directory with new file name, and new directory with old file name
git addthe new file name in the new directory
After you process all files correctly, in the output of
git status you should see the "all conflicts fixed" and all your files renamed.
$ git status rebase in progress; onto cba4321 You are currently rebasing branch 'zz_renaming_haplotypecallergenotypingengine' on 'cba4321'. (all conflicts fixed: run "git rebase --continue") Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngine.java -> protected/gatk-tools-protected/src/main/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/HaplotypeCallerGenotypingEngine.java renamed: protected/gatk-tools-protected/src/test/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/GenotypingEngineUnitTest.java -> protected/gatk-tools-protected/src/test/java/org/broadinstitute/gatk/tools/walkers/haplotypecaller/HaplotypeCallerGenotypingEngineUnitTest.java Untracked files: (use "git add <file>..." to include in what will be committed) <<< possible untracked files if your working directory is not clean>>> $
Continue your rebase, handling other merges as normal.
$ git rebase --continue
Because all the packages names are different in 3.2, while rebasing you may run into conflicts due to imports you also changed. Use your favorite editor to fix the imports within the files. Then try recompiling, and repeat as necessary until your code works.
While editing the files with conflicts with a basic text editor may work, IntelliJ IDEA also offers a special merge tool that may help via the menu:
VCS > Git > Resolve Conflicts...
For each file, click on the "Merge" button in the first dialog. Use the various buttons in the Conflict Resolution Tool to automatically accept any changes that are not in conflict. Then find any edit any remaining conflicts that require further manual intervention.
Once you begin editing the import statements in the three way merge tool, another IntelliJ IDEA 13.1 feature that may speed up repairing blocks of import statements is Multiple Selections. Find a block of import lines that need the same changes. Hold down the option key as you drag your cursor vertically down the edit point on each import line. Then begin typing or deleting text from the multiple lines.
Even after a successful merge, you may still run into stale GATK code or links from modifications before and after the 3.2 package renaming. To significantly reduce these chances, run
mvn clean before and then again after switching branches.
If this doesn't work, run
mvn clean && git status, looking for any directories you don't that shouldn't be in the current branch. It is possible that some files were not correctly moved, including classes or test resources. Find the file still in the old directories via a command such as
find public/gatk-framework -type f. Then move them to the correct new directories and commit them into git.
Due to the [Renamed Binary Packages], the separate artifacts including and excluding private code are now packaged during the Maven package build lifecycle.
When building packages, to significantly speed up the default packaging time, if you only require the GATK tools run
mvn verify -P\!queue.
Alternatively, if you do not require building private source, then disable private compiling via
mvn verify -P\!private.
The two may be combined as well via:
mvn verify -P\!queue,\!private.
The exclamation mark is a shell command that must be escaped, in the above case with a backslash. Shell quotes may also be used:
mvn verify -P'!queue,!private'.
Alternatively, developers with access to private may often want to disable packaging the protected distributions. In this case, use the
gsadev profile. This may be done via
mvn verify -Pgsadev or, excluding Queue,
mvn verify -Pgsadev,\!queue.
Users see errors from maven when an unclean repo in git is updated.
Because BaseTest.java currently hardcodes relative paths to
"public/testdata", maven creates these symbolic links all over the
file system to help the various tests in different modules find the
relative path "
However, our Maven support has evolved from 2.8, to 3.0, to now the 3.2 renaming, each time has changed the symbolic link's target directory. Whenever a stale symbolic link to an old testdata directory remains in the users folder, maven is saying it will not remove the link, because maven basically doesn't know why the link is pointing to the wrong folder (answer, the link is from an old git checkout) and thinks it's a bug in the build.
If one doesn't have an stale / unclean maven repo when updating git via merge/rebase/checkout, you will never see this issue.
The script that can remove the stale symlinks,
public/src/main/scripts/shell/delete_maven_links.sh, should run automatically during a
mvn test-compile or
Since GATK 3.0, we use Apache Maven (instead of Ant) as our build system, and IntelliJ as our IDE (Integrated Development Environment). This document describes how to get set up to use Maven as well as how to create an IntelliJ project around our Maven project structure.
Check whether you can run
mvn --version on your machine. If you can't, install Maven from here.
Ensure that the JAVA_HOME environment variable is properly set. If it's not, add the appropriate line to your shell's startup file:
setenv JAVA_HOME \`/usr/libexec/java_home\`
Note that the commands above use backticks, not single quotes.
To compile everything, type:
To compile the GATK but not Queue (much faster!), the command is:
mvn verify -P\!queue
Note that the
! needs to be escaped with a backslash to avoid interpretation by the shell.
To obtain a clean working directory, type:
If you're used to using ant to compile the GATK, you should be able to feed your old ant commands to the
ant-bridge.sh script in the root directory. For example:
./ant-bridge.sh test -Dsingle=MyTestClass
mvn test-compile in your git clone's root directory.
File -> import project, select your git clone directory, then click "ok"
On the next screen, select "import project from external model", then "maven", then click "next"
Click "next" on the next screen without changing any defaults -- in particular:
On the "Select Profiles" screen, make sure private and protected ARE checked, then click "next".
On the next screen, the "gatk-aggregator" project should already be checked for you -- if not, then check it. Click "next".
Select the 1.7 SDK, then click "next".
Select an appropriate project name (can be anything), then click "next" (or "finish", depending on your version of IntelliJ).
Click "Finish" to create the new IntelliJ project.
That's it! Due to Maven magic, everything else will be set up for you automatically, including modules, libraries, Scala facets, etc.
We're replacing Ant with Maven. To build, run
In the early days of the Genome Analysis Toolkit (GATK), the code base separated the GATK genomics engine from the core java utilities, encompassed in a wider project called Sting. During this time, the build tool of choice was the relatively flexible Java build tool Apache Ant, run via the command
As our code base expanded to more and more packages, groups internal and external to GSA, and the Broad, have expressed interest in using portions of Sting/GATK as modules in larger projects. Unfortunately over time, many parts of the GATK and Sting intermingled, producing the current situation where developers finds it easier to copy the monolithic GATK instead, or individual java files, instead of using the tools as libraries.
The goal of this first stage is to split the parts of the monolithic Sting/GATK into easily recognizable sub artifacts. The tool used to accomplish this task is Apache Maven, also known as Maven, and run via the command
mvn. Maven convention encourages developers to separate code, and accompanying resources, into a hierarchical structure of reusable artifacts. Maven attempts to avoid build configuration, preferring source repositories to lay out code in a conventional structure. When needed, a Maven configuration file called pom.xml specifies each artifact's build configuration, that one may think of as similar to an Ant build.xml.
The actual migration consisted of zero changes to the contents of existing Java source files, easing git merges and rebasing. The Java files from public, protected, and private have all moved into Maven conventional child artifacts, with each artifact containing a separate pom.xml.
Clone the repository:
git clone ssh://firstname.lastname@example.org/broadinstitute/gsa-unstable.git cd gsa-unstable
Clone the repository:
git clone ssh://email@example.com/broadinstitute/gsa-unstable.git cd gsa-unstable
If running on a Broad server, add maven to your environment via the dotkit:
Build all of Sting, including packaged versions of the GATK and Queue:
The packaged, executable jar files will be output to:
Find equivalent maven commands for existing ant targets:
./ant-bridge.sh <target> <properties>
$ ./ant-bridge.sh fasttest -Dsingle=GATKKeyUnitTest Equivalent maven command mvn verify -Dsting.committests.skipped=false -pl private/gatk-private -am -Dresource.bundle.skip=true -Dit.test=disabled -Dtest=GATKKeyUnitTest $
To run the GATK, or copy the compiled jar, find the packaged jar under public/gatk-package/target
To run Queue, the jar is under the similarly named public/queue-package/target
NOTE: Unlike builds with Ant, you cannot execute the jar file built by the gatk-framework module. This is because maven does not include dependent artifacts in the target folder with assembled framework jar. Instead, use the packaged jars, listed above, that contain all the classes and resources needed to run the GATK, or Queue.
NOTE: If you make changes to sting-utils, gatk-framework, or any other dependencies and disable queue, you may accidentally end up breaking the full repository build without knowing.
The Queue build contributes a majority portion of the Sting project build time. To exclude Queue from your build, run maven with either (the already shell escaped)
-Ddisable.queue. Currently the latter property also disables the maven queue profile. This allows one other semi-permanent option to disable building Queue as part of the Sting repository. Configure your local Maven settings to always pass the property
-Ddisable.queue by adding and activating a custom profile in your local ~/.m2/settings.xml
```$ cat ~/.m2/settings.xml
Currently the GATK artifacts are not available via any centralized repository. To build code using the GATK you must still have a checkout of the GATK source code, and install the artifacts to your local mvn repository (by default ~/.m2/repository). The installation copies the artifacts to your local repo such that it may be used by your external project. The checkout of the local repo provides several artifacts under
public/repo that will be required for your project.
After updating to the latest version of the Sting source code, install the Sting artifacts via:
After the GATK has been installed locally, in your own source repository, include the artifact gatk-framework as a library.
In Apache Maven add this dependency:
For Apache Ivy, you may need to specify
~/.m2/repository as a local repo. Once the local repository has been configured, ivy may find the dependency via:
<dependency org="org.broadinstitute.sting" name="gatk-framework" rev="2.8-SNAPSHOT" />
If you decide to also use Maven to build your project, your source code should go under the conventional directory
pom.xml contains any special configuration for your project. To see an example pom.xml and maven conventional project structure in:
If you have an old git branch that needs to be merged, you may need to know where to move files in order for your classes to now build with Maven. In general, most directories were moved with minimal or no changes.
|Old directory||New maven directory|
Currently, the artifacts sting-utils and the gatk-framework contain intertwined code bases. This leads to the current setup where all sting-utils code is actually found in the gatk-framework artifact, including generic utilities that could be used by other software modules. In the future, all elements under
org.broadinstitute.sting.gatk will be located the gatk-framework, while all other packages under
org.broadinstitut.sting will be evaluated and then separated under the gatk-framework or sting-utils artifacts.
Tangentially related to segregating sting-utils and the gatk-framework, the current Sting and GATK artifacts are ineligible to be pushed to the Maven Central Repository, due to several other issues:
NOTE: Artifact jars do NOT need to actually be in Central, and may be available as pom reference only, for example Oracle ojdbc.
In the near term, we could use a private repos based on Artifactory or Nexus (comparison). After more work of adding, cleaning up, or centrally publishing all the dependencies for Sting, we may then publish into the basic Central repo. Or, we could move to a social service like BinTray (think GitHub vs. Git).
Maven is now the default in gsa-unstable's master branch. For GATK developers, the git migration is effectively complete. Software engineers are resolving a few remaining issues related to the automated build and testing infrastructure, but the basic workflow for developers should now be up to date.
The migration to to maven has begun in the gsa-unstable repository on the ks_new_maven_build_system branch.
The maven port of the existing ant build resides in the gsa-qc repository.
This is an old branch of Sting/GATK, with the existing files relocated to Maven appropriate locations, pom.xml files added, along with basic resources to assist in artifact generation.
I was wondering if it is possible to obtain the source code that accompanies the nightly builds; looking at the protected github repository, it seems that the nightly builds are changing faster than the repository there.
My current issue is that I would like the "AD" annotation for homozygous referent samples coming from the GenotypeGVCFs tool. Reading the forum, I believe that this is currently fixed in the nightly builds. However, I have a couple of customizations (pending review) that I don't think are in the nightly builds just yet, so I would need the source to apply my changes and then build.
I realize that I'm asking for something VERY dangerous and completely unsupported; I'm just too darn impatient to wait for the next release :).
Hi, this took me a while to debug, so I'm posting the solution here. I started by downloading a clean copy of GATK core platform from GitHub. When I first tried building by running ant, I got the compiler errors below. The reason turned out to be that an unrelated jar (gsea2-2.0.12.jar) was on my CLASSPATH (this is from another Broad tool I've been using - Gene Set Enrichment Analysis). gsea2-2.0.12.jar apparently contains outdated versions of apache math and io packages which conflict with the GATK versions. Taking this jar off my CLASSPATH fixed the issue.
Ps. the compiler errors were:
gatk.compile.internal.source: [javac] Compiling 681 source files to /prog/GATK/gatk_platform_git/build/java/classes [javac] /prog/GATK/gatk_platform_git/public/java/src/org/broadinstitute/sting/commandline/ParsingEngine.java:260: error: incompatible types [javac] for (String line: FileUtils.readLines(file)) [javac] ^ [javac] required: String [javac] found: Object [javac] /prog/GATK/gatk_platform_git/public/java/src/org/broadinstitute/sting/utils/MannWhitneyU.java:50: error: no suitable constructor found for NormalDistributionImpl(double,double,double) [javac] private static NormalDistribution APACHE_NORMAL = new NormalDistributionImpl(0.0,1.0,1e-2); [javac] ^ [javac] constructor NormalDistributionImpl.NormalDistributionImpl() is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor NormalDistributionImpl.NormalDistributionImpl(double,double) is not applicable [javac] (actual and formal argument lists differ in length) [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 2 errors BUILD FAILED /prog/GATK/gatk_platform_git/build.xml:454: Compile failed; see the compiler error output for details.