buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <>
Subject Re: New buildr user questions
Date Wed, 10 Feb 2010 06:06:29 GMT
More comments below :)

On Tue, Feb 9, 2010 at 21:18, Kevin Smith <> wrote:

> Thanks again. Comments below.
> On Tue, 2010-02-09 at 20:48 -0800, Antoine Toulme wrote:
> >         It would be great if you could add something like this to the
> >         user guide.
> > Could you help us by opening a bug on this ?
> Yes, I will do that.
> > You want to convert an artifact into a file ? It's more the other way
> > around:
> >
> Buildr::artifact("group:artifact:extension:version").from(_("target/")
> No, I really do want to convert an artifact to a file, and not the other
> way around. For example, I want to copy a third-party jar (artifact)
> directly into an ISO image.
Then it will be: ... oh no need Alexis replied.

> > The enhance method comes from rake. Everything in buildr is based on
> > rake.
> Yes, that is one of the frustrations of the buildr documentation. I have
> used rake extensively in the past, but it was several years ago. It
> would be great to have one document that covers buildr+rake. I know it
> would be difficult. Hopefully you can at least continue to add examples
> and other documentation to mention the useful parts of rake as they
> apply in a buildr context.
> With javadocs, at least when you are looking at a class, you get to see
> all the methods that were inherited. rubydocs would be much nicer if
> they could do that as well.
rdocs are published, here is the url:

> > That sounds like custom stuff. I would rather define a task with a
> > different name for that.
> Ok. So let's say I want to create 'justjars' and 'fullrelease' tasks in
> my master project.
> >         The final outcome of my project is a jar with an associated
> >         sha1 file,
> >         a .iso file, a .exe file, a zip file, another zip file, and a
> >         few other
> >         files. In my mind, running 'buildr build' shouldn't actually
> >         create all
> >         those final files. I would think I would run 'buildr package',
> >         but that
> >         doesn't seem to work.
> > You could define an other subproject that would call those.
> > That's what I would do, and it would depend on the other subprojects.
> > The main project is not called because it contains "nothing", no
> > source files in particular.
> Ah, got it. I actually had it before, but was looking in the wrong place
> for the output. Something like this, which seems to work:
>  task 'justjars' => [project('part1').package(:jar),
>         project('part2').package(:jar)]
> And hopefully this (which I haven't been able to test yet):
>  task 'fullrelease' => [project('iso').iso, project('exe').exe]
> Assuming I create custom iso and exe tasks in the sub-projects. Does
> that sound about right?
In that subproject, I would use normal tasks. The reason behind that if that
if you do buildr fullrelease, I'm not sure it's going to trigger it, since
it hasn't been declared on the project task.
I would enhance selectively depending on a global variable.

Here is something that can help:

you create your subproject like that:
define("fullrelease") do
  package.enhance [project('part1').package(:jar),
  package.enhance [some more tasks] if ENV['fullrelease']


But then, it really only helps if you are going to do something with those
What I would suggest is that you don't declare that subproject and use
directly the ENV['fullrelease'] trick in the subproject that defines the iso

In the end, it might also be worth considering not putting in the same
Buildfile the iso and the jars if they have different lifecycle. You'll be
better off using a fixed version of the jars, and you will be able to mess
up with the iso at will.

So to set the global variable, you run Buildr like so:

buildr package fullrelease=true

I hope this helps.


> Kevin

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