Class Buildr::Project
In: lib/buildr/scala/doc.rb  (CVS)
lib/buildr/shell.rb  (CVS)
lib/buildr/groovy/doc.rb  (CVS)
lib/buildr/run.rb  (CVS)
lib/buildr/java/doc.rb  (CVS)
lib/buildr/java/ant.rb  (CVS)
lib/buildr/java/compiler.rb  (CVS)
lib/buildr/java/cobertura.rb  (CVS)
lib/buildr/java/packaging.rb  (CVS)
lib/buildr/java/emma.rb  (CVS)
lib/buildr/ide/idea.rb  (CVS)
lib/buildr/ide/eclipse/java.rb  (CVS)
lib/buildr/ide/eclipse/scala.rb  (CVS)
lib/buildr/ide/eclipse/plugin.rb  (CVS)
lib/buildr/ide/eclipse.rb  (CVS)
lib/buildr/core/doc.rb  (CVS)
lib/buildr/core/build.rb  (CVS)
lib/buildr/core/project.rb  (CVS)
lib/buildr/core/compile.rb  (CVS)
lib/buildr/core/cc.rb  (CVS)
lib/buildr/core/test.rb  (CVS)
lib/buildr/core/checks.rb  (CVS)
lib/buildr/packaging/gems.rb  (CVS)
lib/buildr/packaging/package.rb  (CVS)
addon/buildr/jibx.rb  (CVS)
addon/buildr/hibernate.rb  (CVS)
addon/buildr/protobuf.rb  (CVS)
addon/buildr/jaxb_xjc.rb  (CVS)
addon/buildr/antlr.rb  (CVS)
addon/buildr/javacc.rb  (CVS)
addon/buildr/bnd.rb  (CVS)
addon/buildr/openjpa.rb  (CVS)
Parent: Object

A project definition is where you define all the tasks associated with the project you‘re building.

The project itself will define several life cycle tasks for you. For example, it automatically creates a compile task that will compile all the source files found in src/main/java into target/classes, a test task that will compile source files from src/test/java and run all the JUnit tests found there, and a build task to compile and then run the tests.

You use the project definition to enhance these tasks, for example, telling the compile task which class path dependencies to use. Or telling the project how to package an artifact, e.g. creating a JAR using package :jar.

You can also define additional tasks that are executed by project tasks, or invoked from rake.

Tasks created by the project are all prefixed with the project name, e.g. the project foo creates the task foo:compile. If foo contains a sub-project bar, the later will define the task foo:bar:compile. Since the compile task is recursive, compiling foo will also compile foo:bar.

If you run:

  buildr compile

from the command line, it will execute the compile task of the current project.

Projects and sub-projects follow a directory heirarchy. The Buildfile is assumed to reside in the same directory as the top-level project, and each sub-project is contained in a sub-directory in the same name. For example:

  /home/foo
  |__ Buildfile
  |__ src/main/java
  |__ foo
      |__ src/main/java

The default structure of each project is assumed to be:

  src
  |__main
  |  |__java           <-- Source files to compile
  |  |__resources      <-- Resources to copy
  |  |__webapp         <-- For WARs
  |__test
  |  |__java           <-- Source files to compile (tests)
  |  |__resources      <-- Resources to copy (tests)
  |__target            <-- Packages created here
  |  |__classes        <-- Generated when compiling
  |  |__resources      <-- Copied (and filtered) from resources
  |  |__test/classes   <-- Generated when compiling tests
  |  |__test/resources <-- Copied (and filtered) from resources
  |__reports           <-- Test, coverage and other reports

You can change the project layout by passing a new Layout to the project definition.

You can only define a project once using define. Afterwards, you can obtain the project definition using project. The order in which you define projects is not important, project definitions are evaluated when you ask for them. Circular dependencies will not work. Rake tasks are only created after the project is evaluated, so if you need to access a task (e.g. compile) use project(‘foo’).compile instead of task(‘foo:compile’).

For example:

  define 'myapp', :version=>'1.1' do

    define 'wepapp' do
      compile.with project('myapp:beans')
      package :war
    end

    define 'beans' do
      compile.with DEPENDS
      package :jar
    end
  end

  puts projects.map(&:name)
  => [ 'myapp', 'myapp:beans', 'myapp:webapp' ]
  puts project('myapp:webapp').parent.name
  => 'myapp'
  puts project('myapp:webapp').compile.classpath.map(&:to_spec)
  => 'myapp:myapp-beans:jar:1.1'

Methods

_   base_dir   base_dir=   clear   define   file   layout   layout=   local_task   on_define   path_to   project   projects   recursive_task   task  

Included Modules

ScaladocDefaults Packaging::Scala Shell GroovydocDefaults Run JavadocDefaults Ant Buildr::Apt CoberturaExtension Buildr::Packaging::Java EmmaExtension Buildr::IntellijIdea::ProjectExtension Buildr::Eclipse::Java Buildr::Eclipse::Scala Buildr::Eclipse::Plugin Buildr::Eclipse Doc Buildr::Build Buildr Buildr::Compile CC Buildr::Test Buildr::Checks PackageAsGem Buildr::Package JiBX Hibernate Protobuf Buildr::JaxbXjc ANTLR JavaCC Buildr::Bnd::ProjectExtension OpenJPA

Attributes

name  [R]  The project name. For example, ‘foo’ for the top-level project, and ‘foo:bar’ for its sub-project.
parent  [R]  The parent project if this is a sub-project.

Public Class methods

Discard all project definitions.

Defines a local task with an optional execution message.

A local task is a task that executes a task with the same name, defined in the current project, the project‘s with a base directory that is the same as the current directory.

Complicated? Try this:

  buildr build

is the same as:

  buildr foo:build

But:

  cd bar
  buildr build

is the same as:

  buildr foo:bar:build

The optional block is called with the project name when the task executes and returns a message that, for example "Building project #{name}".

Deprecated Check the Extension module to see how extensions are handled.

Public Instance methods

_(*names)

Alias for path_to

Returns the project‘s base directory.

The Buildfile defines top-level project, so it‘s logical that the top-level project‘s base directory is the one in which we find the Buildfile. And each sub-project has a base directory that is one level down, with the same name as the sub-project.

For example:

  /home/foo/          <-- base_directory of project 'foo'
  /home/foo/Buildfile <-- builds 'foo'
  /home/foo/bar       <-- sub-project 'foo:bar'

Creates and returns a new file task in the project. Similar to calling Rake‘s file method, but the path is expanded relative to the project‘s base directory, and the task executes in the project‘s base directory.

For example:

  define 'foo' do
    define 'bar' do
      file('src') { ... }
    end
  end

  puts project('foo:bar').file('src').to_s
  => '/home/foo/bar/src'

Returns the layout associated with this project.

Returns a path from a combination of name, relative to the project‘s base directory. Essentially, joins all the supplied names and expands the path relative to base_dir. Symbol arguments are converted to paths based on the layout, so whenever possible stick to these. For example:

  path_to(:source, :main, :java)
  => 'src/main/java'

Keep in mind that all tasks are defined and executed relative to the Buildfile directory, so you want to use path_to to get the actual path within the project as a matter of practice.

For example:

  path_to('foo', 'bar')
  => foo/bar
  path_to('/tmp')
  => /tmp
  path_to(:base_dir, 'foo') # same as path_to('foo")
  => /home/project1/foo

Same as Buildr#project. This method is called on a project, so a relative name is sufficient to find a sub-project.

When called on a project without a name, returns the project itself. You can use that when setting project properties, for example:

  define 'foo' do
    project.version = '1.0'
  end

Same as Buildr#projects. This method is called on a project, so relative names are sufficient to find sub-projects.

Define a recursive task. A recursive task executes itself and the same task in all the sub-projects.

Creates and returns a new task in the project. Similar to calling Rake‘s task method, but prefixes the task name with the project name and executes the task in the project‘s base directory.

For example:

  define 'foo' do
    task 'doda'
  end

  puts project('foo').task('doda').name
  => 'foo:doda'

When called from within the project definition, creates a new task if the task does not already exist. If called from outside the project definition, returns the named task and raises an exception if the task is not defined.

As with Rake‘s task method, calling this method enhances the task with the prerequisites and optional block.

Protected Instance methods

Sets the project‘s base directory. Allows you to specify a base directory by calling this accessor, or with the :base_dir property when calling define.

You can only set the base directory once for a given project, and only before accessing the base directory (for example, by calling file or path_to). Set the base directory. Note: you can only do this once for a project, and only before accessing the base directory. If you try reading the value with base_dir, the base directory cannot be set again.

Define a new sub-project within this project. See Buildr#define.

Sets the project layout. Accepts Layout object or class (or for that matter, anything that can expand).

[Validate]