Packages

  • package root
    Definition Classes
    root
  • package com
    Definition Classes
    root
  • package typesafe
    Definition Classes
    com
  • package sbt
    Definition Classes
    typesafe
  • package web
    Definition Classes
    sbt
  • package incremental

    The incremental task API lets tasks run more quickly when they are called more than once.

    The incremental task API lets tasks run more quickly when they are called more than once. The idea is to do less work when tasks are called a second time, by skipping any work that has already been done. In other words, tasks only perform the “incremental” work that is necessary since they were last run.

    To analyse which work needs to be done, a task’s work is broken up into a number of sub-operations, each of which can be run independently. Each operation takes input parameters and can read and write files. The incremental task API keeps a record of which operations have been run so that that those operations don’t need to be repeated in the future.

    Here is how tasks interact with the API:

    - Tasks call the API with a list of potential operations to perform and with a function to run operations.

    - The API takes care of pruning the list of operations to find the incremental operations that need to be run.

    - The API then calls the supplied function to run the pruned list of operations. This method returns a list of results, one for each operation.

    - If an operation succeeds, the details are recorded so that the operation can be skipped in the future, if possible.

    Behind the scenes, syncIncremental maintains a record of each operation that succeeds. It uses these records to work out which operations need to be run and which can be skipped.

    Each operation is assumed to take some input parameters, optionally read and write some files, and either succeed or fail when it runs. An operation which fails will always be run again even if its parameters and input files remain the same. But an operation which succeeds will only need to be run again if its input parameters change or if the contents of any files it read from or wrote to have changed.

  • package js
  • package pipeline
  • CompileProblems
  • CompileProblemsException
  • GeneralProblem
  • Import
  • LineBasedProblem
  • LinePosition
  • SbtWeb

package web

Linear Supertypes
AnyRef, Any
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. web
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Type Members

  1. class CompileProblemsException extends CompileFailed with sbt.FeedbackProvidedException

    Exception thrown by CompileProblems.report if there are any problems to report.

    Exception thrown by CompileProblems.report if there are any problems to report. This exception contains the problems so they can be used for further processing (e.g. for display by Play).

  2. type Deduplicator = (Seq[File]) ⇒ Option[File]

    A function for possibly selecting a single file from a sequence.

  3. class GeneralProblem extends Problem

    Capture a general problem with the compilation of a source file.

    Capture a general problem with the compilation of a source file. General problems have no associated line number and are always regarded as errors.

  4. class LineBasedProblem extends Problem

    Capture a problem associated with a line number and character offset.

  5. class LinePosition extends Position

    Capture a line/column position along with the line's content for a given source file.

  6. type PathMapping = (File, String)

    Describes a string path relative to a base directory.

Value Members

  1. object CompileProblems
  2. object Import
  3. object SbtWeb extends AutoPlugin

    Adds settings concerning themselves with web things to SBT.

    Adds settings concerning themselves with web things to SBT. Here is the directory structure supported by this plugin showing relevant sbt settings:

    + src
--+ main
----+ assets .....(sourceDirectory in Assets)
------+ js
----+ public .....(resourceDirectory in Assets)
------+ css
------+ images
------+ js
--+ test
----+ assets .....(sourceDirectory in TestAssets)
------+ js
----+ public .....(resourceDirectory in TestAssets)
------+ css
------+ images
------+ js

+ target
--+ web
----+ public
------+ main
--------+ css
--------+ images
--------+ js
------+ test
--------+ css
--------+ images
--------+ js
----+ stage

    The plugin introduces the notion of "assets" to sbt. Assets are public resources that are intended for client-side consumption e.g. by a browser. This is also distinct from sbt's existing notion of "resources" as project resources are generally not made public by a web server. The name "assets" heralds from Rails.

    "public" denotes a type of asset that does not require processing i.e. these resources are static in nature.

    In sbt, asset source files are considered the source for plugins that process them. When they are processed any resultant files become public. For example a coffeescript plugin would use files from "unmanagedSources in Assets" and produce them to "public in Assets".

    All assets be them subject to processing or static in nature, will be copied to the public destinations.

    How files are organised within "assets" or "public" is subject to the taste of the developer, their team and conventions at large.

    The "stage" directory is product of processing the asset pipeline and results in files prepared for deployment to a web server.

Inherited from AnyRef

Inherited from Any

Ungrouped