buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: Tasks, Filters etc.
Date Mon, 03 May 2010 13:31:28 GMT
Hi Ingo!

On Mon, May 3, 2010 at 12:54 AM, Ingo Schmidt <> wrote:

> I have been using buildr successfully for quite a while now. Everything
> works fine so far, however, now with some more experience I wanted to clean
> my build files. But this turned out not to be so easy.
> Here a short overview of what I am building:
> An EAR with some WARs inside. The WARs use a JAR artifact, the framework.
> This artifact contains a template properties file along with a YAML file
> which contains default values. For each WAR this file must be run through a
> filter to set WAR specific settings and be included in the WAR.
> Here are my questions:
> 1. Right now I have a few "require" directives in my buildfile which run a
> couple of pre-build tasks:
> - unzip the properties template and its default YAML file
> - merge the default YAML file with WAR specific YAML file
> What I do not like about the current approach:
> The unzipping and merging is done no matter what, even for the clean task
> where I dont need it. I would like to run this unzipping and merging like
> that:
> - before the actual building
> - only for the build task
> - only once for the whole build process
> I tried this by enhancing the build task, but...

I don't have all the details but here's a prototype of what this could look

define 'custom-war' do
  jar = project("framework").package(:jar)

  unzip(_("target/framework") => jar)

  custom_yaml = file(_(:target, "custom.yaml") => _(:target, "framework"))
do |f|
    custom_config = { ... }
    default_yaml = read_yaml(_(:target, "framework/config.yaml"))
    write_yaml f, default_yaml.merge(custom_config)

  package(:war).enhance custom_yaml  # set up dependency
  package(:war).path('WEB-INF/config').include custom_yaml


The important point here is using tasks and wiring them together instead of
using just the "build" task.   By creating file tasks, such as unzip() or
file("custom.yaml"), then you're stating that these tasks should only be run
if the target doesn't exist or isn't up-to-date.  You can also see how the
dependencies are wired such that if one file changes, then there's a cascade
of changes.

I hope this gets you started in the right direction.

> 2. consider this very simple buildfile:
> desc "The Buildr-test project"
> define "buildr-test" do
>  project.version = VERSION_NUMBER
>  manifest["Implementation-Vendor"] = COPYRIGHT
>  build do
>    puts "main"
>  end
>  define "app-war" do
>    build do
>      puts "my app"
>    end
>    package(:war)
>  end
> end
> --------------- snap --------------
> If you run buildr with it, you will notice that it outputs in the following
> order:
> Building buildr-test
> my app
> main
> If "main" came before "my app" I would put the stuff I want to do there and
> be happy. But since it is not like that I am a little bit stuck.
Yes, this is expected (and spec'ed) behavior.  Parent projects implicitly
depend on child projects, so children get built first, then parents.   If
you wire your tasks properly then this shouldn't be a problem -- in fact it
should be welcome behavior.

> 3. Including/Excluding files
> I have seen issue BUILDR-335, but I still have a questions about excluding
> files:
> Let's say I want to exclude a folder called "dummy" with all its contents
> from my webapp folder:
> package(:war).exclude("**/dummy")
> Now this will remove ALL folders called "dummy" somewhere in my directory
> tree. Clearly I do not want this.
> So I tried:
> package(:war).exclude("**/webapp/dummy")
> Now this worked. It is a workaround I can live with, but I never found out
> what the full path to my dummy folder would be. I must say, the whole
> process of including and excluding is still very mysterious to me.

Unfortunately, I don't have a good answer for this right now.  I agree it's
confusing and we'll try to fix this in a later release.   If the above works
for you, I'd stick with it for the time being.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message