Java build tools and SBT most rapid experience

In response to Java projects, we probably have the following several automated build tools:

Ant-XML cross-platform batch, configuration file Build.xml, executing target
Maven-Starts standardizing the directory layout, based on the project object model, configuration file Pom.xml, executing the Phase/goal
Gradle--Use Maven default layout, Groove language cast, configuration is Build.gradle file in groovy syntax, execute task
Buildr-Default is the Maven directory layout, the Java world is in Ruby's hands, configuration is a buildfile file in Ruby syntax, and task
Leiningen--Also in the Maven directory layout, written by Clojure, used to build Java and Clojure projects, configuration files are PRJECT.CLJ of Clojure syntax, based on task
SBT-Default Maven directory layout, Scala (simple) build Tool, Scala, building Java and Scala projects, configuration is the BUILD.SBT of Scala syntax, based on task. Interactive console.
Ant lets us get rid of the system platform dependence, finally the different person constructs the work piece is the same, once it is to show agile. In addition to the ANT's need for us to define all of the target, the other builds have a basic enough task built into it, and they all employ the industry-accepted Maven directory layout. It's also the introduction of project dependency Management from Maven, so Maven is a milestone.

We often go into pages like this when we search for Java third party dependencies http://mvnrepository.com/artifact/com.google.guava/guava/19.0

I also found out from here that there are so many build tools to choose from, where Ivy is an Ant based dependency management tool, and Grape is Groovy's dependency management tool. Know that SBT is also using Ivy to manage dependence.

Here does not specifically comment on which of the above building tools long and short, estimated Ant has been less used, Maven still has a large number of Fans bar it; Android Studio loves to use Gradle. Because I've been using the play Framework to use Java and Scala for the time being, so I'm basically immersed in SBT.

So take a look at SBT how to build a project quickly, although we say SBT's configuration file is BUILD.SBT, this is optional, and other build tools must provide a configuration file.

Assuming you have installed the SBT, use a command mkdir-p test/src/{main,test}/{java,scala,resources under the *nix system; CD test; SBT creates and enters the SBT Interactive console

➜~ mkdir-p test/src/{main,test}/{java,scala,resources}; CD test; SBt
[INFO] Set current project to test (in build file:/users/uqiu/test/)
> Tasks

This is a list of tasks defined to the current project.
It does not list the scopes the tasks are defined in; Use the ' inspect ' command for that.
Tasks produce values. Use the "show" command to run the task and print the resulting value.

Clean deletes files produced by the build, such as generated sources, compiled classes, and task caches.
Compile compiles sources.
Console starts the Scala interpreter with the project classes on the classpath.
Consoleproject starts the Scala interpreter with the SBT and the builds definition on the classpath and useful imports.
Consolequick starts the Scala interpreter with the project dependencies on the classpath.
Copyresources copies to the output directory.
Doc generates API documentation.
Package produces the main artifact, such as a binary jar. This is typically a alias for the task that actually does the packaging.
Packagebin produces a main artifact, such as a binary jar.
Packagedoc produces a documentation artifact, such as a jar containing API documentation.
PACKAGESRC produces a source artifact, such as a jar containing sources and resources.
Publish publishes artifacts to a repository.
Publishlocal publishes artifacts to the local Ivy repository.
PUBLISHM2 publishes artifacts to the local Maven repository.
Run runs a main class, passing along arguments provided on the command line.
Runmain runs the main class selected by the the "the", passing the remaining arguments to the main method.
Test executes all tests.
Testonly executes the tests provided as arguments or all tests if no arguments are.
Testquick executes the tests that either failed before and were not run or whose transitive dependencies changed G those provided as arguments.
Update resolves and optionally retrieves dependencies, producing a.

More tasks May is viewed by increasing verbosity. ' Help tasks '.

>
The project's default Maven directory layout is created above, and even a configuration file does not allow us to use many of the SBT tasks that are preset for us, tasks-v Show all the built-in tasks.

Let's look at the catalog layout

Test
└──src
├──main
│├──java
│├──resources
│└──scala
└──test
├──java
├──resources
└──scala
Again, create a Java code file Src/main/java/hello.java

public class Hello {
public static void Main (string[] args) {
System.out.println ("Hello world!");
}
}
This article original link http://unmi.cc/java-built-tools-sbt-simplist-project/, from Yehuang Unmi Blog
Back to the front of the SBT console, perform task run

> Run
[INFO] Updating {file:/users/uqiu/test/}test ...
[INFO] Resolving org.fusesource.jansi#jansi;1.4 ...
[INFO] Done updating.
[INFO] Compiling 1 Java Source to/users/uqiu/test/target/scala-2.10/classes ...
[INFO] Running Hello
Hello world!
[Success] Total Time:2 S, completed APR 1, 2016 11:19:02 PM
>
Compiling runs is as simple as compiling only compile and specifying classes with Runmain If there are multiple classes in the project that have the main entry method. The task of adding a ~ symbol on the watch function, monitoring the relevant file changes automatically after the line. ~testonly and ~testquick are particularly useful in TDD project practice.

Ben just wanted to forget about this mkdir-p test/src/{main,test}/{java,scala,resources}; CD test; SBT This order, do not intend to describe the SBT more content and the beginning of space. But still can't help with the content that relies on management, here demonstrate to join guava and junit These two dependencies, then we will create a BUILD.SBT file in the project root directory, the content is as follows

Librarydependencies ++= Seq (
"Com.google.guava"% "guava"% "19.0",
"Com.novocode"% "junit-interface"% "0.11"% "test"
)
This BUILD.SBT can be configured with more information about the project, such as name, version, Scalaversion, and the default value will be applied if not set.

Introducing guava into the product code, and in Scala support for junit testing is introduced into Junit-interface, which automatically joins the dependent JUnit

Then create a test file Src/test/scala/hellotest.scala, content

Import Org.junit.Test
Import Org.junit.Assert.fail

Class Hellotest {
@Test def Testdemo {
Fail ("not implemented.")
}
}
Once again, go back to the SBT console, perform reload and test tasks, and you will see

> Reload
[INFO] Set current project to test (in Build file:/users/uqiu/test/)
> Test
[ERROR] Test Hel Lotest.testdemo Failed:not implemented., took 0.002 sec
[ERROR] Failed:total 1, failed 1, Errors 0, passed 0
[er ROR] Failed tests:
[error]     hellotest
[ERROR] (test:test) SBT. Testsfailedexception:tests unsuccessful
[ERROR] Total time:0 s, completed APR 2, 2016 12:18:07 AM

Other ~ Functions can be experienced, under the SBT console input ~testquick, or   ~test, or ~testonly hellotest, and then modify the Hellotest.scala to see what happened under the SBT console, let you experience the most vivid TDD-Test-driven development.