Add a transform method when merging artifacts to transform file contents
[buildr.git] / doc / extending.textile
1 ---
2 layout: default
3 title: Extending Buildr
4 ---
5
6 h2(#tasks). Organizing Tasks
7
8 A couple of things we learned while working on Buildr.  Being able to write your own Rake tasks is a very powerful feature.  But if you find yourself doing the same thing over and over, you might also want to consider functions. They give you a lot more power and easy abstractions.
9
10 For example, we use OpenJPA in several projects.  It's a very short task, but each time I have to go back to the OpenJPA documentation to figure out how to set the Ant MappingTool task, tell Ant how to define it.  After the second time, you're recognizing a pattern and it's just easier to write a function that does all that for you.
11
12 Compare this:
13
14 {% highlight ruby %}
15 file('derby.sql') do
16   REQUIRES = [
17     'org.apache.openjpa:openjpa-all:jar:0.9.7-incubating',
18     'commons-collections:commons-collections:jar:3.1',
19     . . .
20     'net.sourceforge.serp:serp:jar:1.11.0' ]
21   ant('openjpa') do |ant|
22     ant.taskdef :name=>'mapping',
23       :classname=>'org.apache.openjpa.jdbc.ant.MappingToolTask',
24       :classpath=>REQUIRES.join(File::PATH_SEPARATOR)
25     ant.mapping :schemaAction=>'build', :sqlFile=>task.name,
26       :ignoreErrors=>true do
27         ant.config :propertiesFile=>_('src/main/sql/derby.xml')
28         ant.classpath :path=>projects('store', 'utils' ).
29           flatten.map(&:to_s).join(File::PATH_SEPARATOR)
30     end
31   end
32 end
33 {% endhighlight %}
34
35 To this:
36
37 {% highlight ruby %}
38 file('derby.sql') do
39   mapping_tool :action=>'build', :sql=>task.name,
40     :properties=>_('src/main/sql/derby.xml'),
41     :classpath=>projects('store', 'utils')
42 end
43 {% endhighlight %}
44
45 I prefer the second.  It's easier to look at the Buildfile and understand what it does.  It's easier to maintain when you only have to look at the important information.
46
47 But just using functions is not always enough.  You end up with a Buildfile containing a lot of code that clearly doesn't belong there.  For starters, I recommend putting it in the @tasks@ directory.  Write it into a file with a @.rake@ extension and place that in the @tasks@ directory next to the Buildfile.  Buildr will automatically pick it up and load it for you.
48
49 If you want to share these pre-canned definitions between projects, you have a few more options.  You can share the @tasks@ directory using SVN externals, Git modules, or whichever cross-repository feature your source control system supports. Another mechanism with better version control is to package all these tasks, functions and modules into a "Gem":http://rubygems.org/ and require it from your Buildfile.  You can run your own internal Gem server for that.
50
51 To summarize, there are several common ways to distribute extensions:
52 * Put them in the same place (e.g. @~/.buildr@) and require them from your
53 @buildfile@
54 * Put them directly in the project, typically under the @tasks@ directory.
55 * Put them in a shared code repository, and link to them from your project's @tasks@ directory
56 * As Ruby gems and specify which gems are used in the settings file
57
58 You can also get creative and devise your own way to distribute extensions.
59 "Sake":http://errtheblog.com/post/6069 is a good example of such initiative that lets you deploy Rake tasks on a system-wide basis.
60
61 h2(#extensions).  Creating Extensions
62
63 The basic mechanism for extending projects in Buildr are Ruby modules.  In fact, base features like compiling and testing are all developed in the form of modules, and then added to the core Project class.
64
65 A module defines instance methods that are then mixed into the project and become instance methods of the project.  There are two general ways for extending projects.  You can extend all projects by including the module in Project:
66
67 {% highlight ruby %}
68 class Project
69   include MyExtension
70 end
71 {% endhighlight %}
72
73 You can also extend a given project instance and only that instance by extending it with the module:
74
75 {% highlight ruby %}
76 define 'foo' do
77   extend MyExtension
78 end
79 {% endhighlight %}
80
81 Some extensions require tighter integration with the project, specifically for setting up tasks and properties, or for configuring tasks based on the project definition.  You can do that by adding callbacks to the process.
82
83 The easiest way to add callbacks is by incorporating the Extension module in your own extension, and using the various class methods to define callback behavior.
84
85 |_. Method        |_. Usage |
86 | @first_time@    | This block will be called once for any particular extension.  You can use this to setup top-level and local tasks. |
87 | @before_define@ | This block is called once for the project with the project instance, right before running the project definition.  You can use this to add tasks and set properties that will be used in the project definition. |
88 | @after_define@  | This block is called once for the project with the project instance, right after running the project definition.  You can use this to do any post-processing that depends on the project definition. |
89
90 This example illustrates how to write a simple extension:
91
92 {% highlight ruby %}
93 module LinesOfCode
94
95   include Extension
96
97   first_time do
98     # Define task not specific to any projet.
99     desc 'Count lines of code in current project'
100     Project.local_task('loc')
101   end
102
103   before_define do |project|
104     # Define the loc task for this particular project.
105     project.recursive_task 'loc' do |task|
106       lines = task.prerequisites.map { |path|
107         Dir["#{path}/**/*"]
108       }.uniq.select { |file|
109         File.file?(file)
110       }.inject(0) { |total, file|
111         total + File.readlines(file).count
112       }
113       puts "Project #{project.name} has #{lines} lines of code"
114       end
115   end
116
117   after_define do |project|
118     # Now that we know all the source directories, add them.
119     task('loc' => project.compile.sources + project.test.sources)
120   end
121
122   # To use this method in your project:
123   # loc path_1, path_2
124   def loc(*paths)
125     task('loc' => paths)
126   end
127
128 end
129
130 class Buildr::Project
131     include LinesOfCode
132 end
133 {% endhighlight %}
134
135 You may find interesting that this Extension API is used pervasively inside Buildr itself.  Many of the standard tasks such as @compile@, @test@, @package@  are extensions to a very small core.
136
137 Starting with Buildr 1.4, it's possible to define ordering between @before_define@ and @after_define@ code blocks in a way similar to Rake's dependencies.  For example, if you wanted to override @project.test.compile.from@ in @after_define@, you could do so by in
138
139 {% highlight ruby %}
140 after_define(:functional_tests) do |project|
141   # Change project.test.compile.from if it's not already pointing
142   # to a location with Java sources
143   if Dir["#{project.test.compile.from}/**/*.java"].size == 0 &&
144      Dir["#{project._(:src, 'test-functional', :java)}/**/*.java"].size > 0
145     project.test.compile.from project._(:src, 'test-functional', :java)
146   end
147 end
148
149 # make sure project.test.compile.from is updated before the
150 # compile extension picks up its value
151 after_define(:compile => :functional_test)
152 {% endhighlight %}
153
154 Core extensions provide the following named callbacks: @compile@, @test@, @build@, @package@ and @check@.
155
156 h2(#layouts).  Using Alternative Layouts
157
158 Buildr follows a common convention for project layouts: Java source files appear in @src/main/java@ and compile to @target/classes@, resources are copied over from @src/main/resources@ and so forth.  Not all projects follow this convention, so it's now possible to specify an alternative project layout.
159
160 The default layout is available in @Layout.default@, and all projects inherit it.  You can set @Layout.default@ to your own layout, or define a project with a given layout (recommended) by setting the @:layout@ property.  Projects inherit the layout from their parent projects.  For example:
161
162 {% highlight ruby %}
163 define 'foo', :layout=>my_layout do
164   ...
165 end
166 {% endhighlight %}
167
168 A layout is an object that implements the @expand@ method.  The easiest way to define a custom layout is to create a new @Layout@ object and specify mapping between names used by Buildr and actual paths within the project.  For example:
169
170 {% highlight ruby %}
171 my_layout = Layout.new
172 my_layout[:source, :main, :java] = 'java'
173 my_layout[:source, :main, :resources] = 'resources'
174 {% endhighlight %}
175
176 Partial expansion also works, so you can specify the above layout using:
177
178 {% highlight ruby %}
179 my_layout = Layout.new
180 my_layout[:source, :main] = ''
181 {% endhighlight %}
182
183 If you need anything more complex, you can always subclass @Layout@ and add special handling in the @expand@ method, you'll find one such example in the API documentation.
184
185 The built-in tasks expand lists of symbols into relative paths, using the following convention:
186
187 |_. Path                          |_. Expands to |
188 | @:source, :main, <lang/usage>@  |  Directory containing source files for a given language or usage, for example, @:java@, @:resources@, @:webapp@. |
189 | @:source, :test, <lang/usage>@  | Directory containing test files for a given language or usage, for example, @:java@, @:resources@. |
190 | @:target, :generated@           | Target directory for generated code (typically source code). |
191 | @:target, :main, <lang/usage>@  | Target directory for compiled code, for example, @:classes@, @:resources@. |
192 | @:target, :test, <lang/usage>@  | Target directory for compile test cases, for example, @:classes@, @:resources@. |
193 | @:reports, <framework/usage>@   | Target directory for generated reports, for example, @:junit@, @:coverage@. |
194
195 All tasks are encouraged to use the same convention, and whenever possible, we recommend using the project's @path_to@ method to expand a list of symbols into a path, or use the appropriate path when available.  For example:
196
197 {% highlight ruby %}
198 define 'bad' do
199   # This may not be the real target.
200   puts 'Compiling to ' + path_to('target/classes')
201   # This will break with different layouts.
202   package(:jar).include 'src/main/etc/*'
203 end
204
205 define 'good' do
206   # This is always the compiler's target.
207   puts 'Compiling to ' + compile.target.to_s
208   # This will work with different layouts.
209   package(:jar).include path_to(:source, :main, :etc, '*')
210 end
211 {% endhighlight %}