You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Kevin Smith <ke...@qualitycode.com> on 2010/02/10 02:05:12 UTC
New buildr user questions
Greetings all,
First, let me say that I am generally happy with buildr. I'm a long-time
ruby user and XML hater, so having an alternative to ant/maven is great.
I have managed to get most of my build system working, but have several
problems/questions. If any of these are answered in the online docs,
wiki, jira, or mailing list archives, feel free to just point me in that
direction.
1. How to extract a file from an artifact?
I need to extract the license file out of some third-party jar
artifacts. I can't find any easy way to do that. The best I have come up
with is to create a zip task that includes the artifact. Then, turn
around and unzip the zip, then unzip the jar. Yuck.
2. How to copy artifact files?
This is closely related to #1. My script creates an ISO image. I would
like to simply copy some artifacts into the ISO directory, but don't see
any way to do it. My workaround is to create a zip containing the full
directory structure I want, and then unzipping it into the ISO image.
Seems like it should be easier.
3. How to specify a dependency for a package task?
Several times, I have wanted to specify that the package task for a
project should depend on some other task. In one case, I had a master
project and several related projects (which were not buildr subprojects
because I couldn't get those to work the way I wanted). I simply wanted
to create a 'package' target in the master project, which depends on the
package targets of the other projects. I can see how to do this for
'build', but not for 'package'.
Kevin
Re: New buildr user questions
Posted by Kevin Smith <ke...@qualitycode.com>.
On Tue, 2010-02-09 at 22:02 -0800, Alexis Midon wrote:
> An artifact is (Rake) FileTask, its name is the path to the jar in your
> maven repository.
> And the method Task#to_s returns the name of the task. So what you're
> looking for is Artifact#to_s
>
> So to copy the jar, you can do:
> cp artifact('...').to_s dest
>
> Note that the artifact must have been installed first.
Thank you so much. That was the missing piece. It would be great if the
documentation mentioned that, but even better if artifact had a #path or
at least #name method. For that matter, why doesn't FileTask already
have that?
I will create a jira ticket for this.
Kevin
Re: New buildr user questions
Posted by Alexis Midon <al...@gmail.com>.
On Tue, Feb 9, 2010 at 9:18 PM, Kevin Smith <ke...@qualitycode.com> 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/myfile.zip")
>
> 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.
>
An artifact is (Rake) FileTask, its name is the path to the jar in your
maven repository.
And the method Task#to_s returns the name of the task. So what you're
looking for is Artifact#to_s
So to copy the jar, you can do:
cp artifact('...').to_s dest
Note that the artifact must have been installed first.
Hope it helps,
Alexis
>
> > 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.
>
> > 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?
>
> Kevin
>
>
>
Re: New buildr user questions
Posted by Peter Schröder <ps...@blau.de>.
i think this a good idea. there should at least be some hints!
it is very difficult to understand where methods lice 'enhance' come from, especially for non ruby/rake userers.
kind regards,
peter
Am 12.02.2010 um 06:04 schrieb Kevin Smith:
> On Tue, 2010-02-09 at 22:06 -0800, Antoine Toulme wrote:
>> More comments below :)
>>
>> On Tue, Feb 9, 2010 at 21:18, Kevin Smith <ke...@qualitycode.com> wrote:
>>>
>>> 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:
>> http://buildr.apache.org/rdoc
>
> I realize that the rdoc for rake is published, and the rdoc for buildr
> is published. It would be great if they could be merged, and formatted
> such that when you look at the WarTask, you could see all the inherited
> methods.
>
>
> (snipped good advice about structuring sub-projects)
>> I hope this helps.
>
> I think it does. Now that I have all of the basics working, I can start
> optimizing, simplifying, and clarifying. I'm getting more and more
> comfortable with the syntax and concepts, and as I continue to learn,
> your advice will make more and more sense. This whole project has been
> quite a bit harder than I had hoped, but I think it is turning out well.
>
> Thanks again,
>
> Kevin
>
>
Re: New buildr user questions
Posted by Kevin Smith <ke...@qualitycode.com>.
On Tue, 2010-02-09 at 22:06 -0800, Antoine Toulme wrote:
> More comments below :)
>
> On Tue, Feb 9, 2010 at 21:18, Kevin Smith <ke...@qualitycode.com> wrote:
> >
> > 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:
> http://buildr.apache.org/rdoc
I realize that the rdoc for rake is published, and the rdoc for buildr
is published. It would be great if they could be merged, and formatted
such that when you look at the WarTask, you could see all the inherited
methods.
(snipped good advice about structuring sub-projects)
> I hope this helps.
I think it does. Now that I have all of the basics working, I can start
optimizing, simplifying, and clarifying. I'm getting more and more
comfortable with the syntax and concepts, and as I continue to learn,
your advice will make more and more sense. This whole project has been
quite a bit harder than I had hoped, but I think it is turning out well.
Thanks again,
Kevin
Re: New buildr user questions
Posted by Antoine Toulme <an...@lunar-ocean.com>.
More comments below :)
On Tue, Feb 9, 2010 at 21:18, Kevin Smith <ke...@qualitycode.com> 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/myfile.zip")
>
> 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:
http://buildr.apache.org/rdoc
>
> > 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),
project('part2').package(:jar)]
package.enhance [some more tasks] if ENV['fullrelease']
end
But then, it really only helps if you are going to do something with those
prerequisites.
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
task.
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.
Antoine
> Kevin
>
>
>
Re: New buildr user questions
Posted by Kevin Smith <ke...@qualitycode.com>.
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/myfile.zip")
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.
> 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.
> 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?
Kevin
Re: New buildr user questions
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Hi Kevin, see my comments inline:
On Tue, Feb 9, 2010 at 20:35, Kevin Smith <ke...@qualitycode.com> wrote:
> On Tue, 2010-02-09 at 17:10 -0800, Antoine Toulme wrote:
> > You can declare a unzip task, and build it:
> > build unzip(_("target/jetty")=>artifact(JETTY))
>
> Thanks for your quick reply.
>
> I was unable to decipher this from what I have read in the docs. I can
> see that it starts with the JETTY artifact, but I don't see how that jar
> would end up being copied to the target directory, where it could be
> unzipped.
>
> But I tried it, and it magically works. The introductory docs are great,
> but what is missing is the intermediate level. I would love to
> understand the fundamental rules that describe why this bit of magic
> actually works. It looks like artifact magically exposes an actual file
> to unzip, but I sure don't see any hint of that in the api docs.
>
> Anyway, here is what I ended up with, which seems to work fine:
>
> build do
> dir = _('target', 'jetty')
> license_name = 'LICENSE.html'
> unzip(dir=>artifact(JETTY_SPEC)).include("**/#{license_name}")
> license_file = File.join(dir, 'LICENSE.html')
> install artifact(JETTY_LICENSE_SPEC).from(license_file)
> FileUtils::rm_rf dir
> end
>
> 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 ?
>
> >
> > On Tue, Feb 9, 2010 at 17:05, Kevin Smith <ke...@qualitycode.com>
> wrote:
> > > 2. How to copy artifact files?
> > >
> > > This is closely related to #1. My script creates an ISO image. I would
> > > like to simply copy some artifacts into the ISO directory, but don't
> see
> > > any way to do it. My workaround is to create a zip containing the full
> > > directory structure I want, and then unzipping it into the ISO image.
> > > Seems like it should be easier.
> > >
> > Well, that's pure Ruby, off the top of my head:
> > cp a z
>
> Ok, so now I know how to unzip an artifact (from #1). How to convert an
> artifact into an actual file in _('target') that I can do something
> with? Still can't find it in the docs. The closest I have so far are: I
> could unzip it and then rezip it, or I could include it in a zip and
> then unzip it.
>
You want to convert an artifact into a file ? It's more the other way
around:
Buildr::artifact("group:artifact:extension:version").from(_("target/myfile.zip")
Does it help ?
>
> > > 3. How to specify a dependency for a package task?
> > >
> > > Several times, I have wanted to specify that the package task for a
> > > project should depend on some other task. In one case, I had a master
> > > project and several related projects (which were not buildr subprojects
> > > because I couldn't get those to work the way I wanted). I simply wanted
> > > to create a 'package' target in the master project, which depends on
> the
> > > package targets of the other projects. I can see how to do this for
> > > 'build', but not for 'package'.
> > >
> > You use the enhance method that takes an array as argument:
> >
> > package(:zip).enhance [task1, task2]
>
> I didn't see .enhance anywhere in the docs, so still not quite sure what
> it is supposed to do.
>
The enhance method comes from rake. Everything in buildr is based on rake.
>
> But I'm not sure it matters, because in my case, my master project
> doesn't have a single zip file. I wanted my master project to have an
> "empty" package task, just as you can have an empty build task. When I
> say "buildr package", I want it to invoke several package tasks in other
> projects, each of which create a zip or jar.
>
That sounds like custom stuff. I would rather define a task with a different
name for that.
>
> 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.
>
> So I tried to get my master 'build' task to depend on the other
> packages. It wouldn't be ideal, because sometimes I would just want to
> build enough to test, and other times I would want to take the extra
> time (and prompt the user for passwords) required to create signed jars.
> But I would take a master build task for now, as a starting point.
>
> So far, that hasn't worked either. Here was my latest failed attempt,
> inside the definition of my master project:
>
> build do
> jar = project('utils').package(:jar)
> unzip(_('target/utils')=>jar)
> end
>
> As far as I can tell, it had no effect whatsoever (no errors either).
>
> Would I have to define 'install' tasks in my non-master projects? If so,
> could I automatically invoke them from master:build? It seems wrong to
> run master:install to get all the other project artifacts in place, and
> then do a master:build after that do pull them all into _('target').
>
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.
>
> Kevin
>
>
>
Re: New buildr user questions
Posted by Kevin Smith <ke...@qualitycode.com>.
On Tue, 2010-02-09 at 17:10 -0800, Antoine Toulme wrote:
> You can declare a unzip task, and build it:
> build unzip(_("target/jetty")=>artifact(JETTY))
Thanks for your quick reply.
I was unable to decipher this from what I have read in the docs. I can
see that it starts with the JETTY artifact, but I don't see how that jar
would end up being copied to the target directory, where it could be
unzipped.
But I tried it, and it magically works. The introductory docs are great,
but what is missing is the intermediate level. I would love to
understand the fundamental rules that describe why this bit of magic
actually works. It looks like artifact magically exposes an actual file
to unzip, but I sure don't see any hint of that in the api docs.
Anyway, here is what I ended up with, which seems to work fine:
build do
dir = _('target', 'jetty')
license_name = 'LICENSE.html'
unzip(dir=>artifact(JETTY_SPEC)).include("**/#{license_name}")
license_file = File.join(dir, 'LICENSE.html')
install artifact(JETTY_LICENSE_SPEC).from(license_file)
FileUtils::rm_rf dir
end
It would be great if you could add something like this to the user
guide.
>
> On Tue, Feb 9, 2010 at 17:05, Kevin Smith <ke...@qualitycode.com> wrote:
> > 2. How to copy artifact files?
> >
> > This is closely related to #1. My script creates an ISO image. I would
> > like to simply copy some artifacts into the ISO directory, but don't see
> > any way to do it. My workaround is to create a zip containing the full
> > directory structure I want, and then unzipping it into the ISO image.
> > Seems like it should be easier.
> >
> Well, that's pure Ruby, off the top of my head:
> cp a z
Ok, so now I know how to unzip an artifact (from #1). How to convert an
artifact into an actual file in _('target') that I can do something
with? Still can't find it in the docs. The closest I have so far are: I
could unzip it and then rezip it, or I could include it in a zip and
then unzip it.
> > 3. How to specify a dependency for a package task?
> >
> > Several times, I have wanted to specify that the package task for a
> > project should depend on some other task. In one case, I had a master
> > project and several related projects (which were not buildr subprojects
> > because I couldn't get those to work the way I wanted). I simply wanted
> > to create a 'package' target in the master project, which depends on the
> > package targets of the other projects. I can see how to do this for
> > 'build', but not for 'package'.
> >
> You use the enhance method that takes an array as argument:
>
> package(:zip).enhance [task1, task2]
I didn't see .enhance anywhere in the docs, so still not quite sure what
it is supposed to do.
But I'm not sure it matters, because in my case, my master project
doesn't have a single zip file. I wanted my master project to have an
"empty" package task, just as you can have an empty build task. When I
say "buildr package", I want it to invoke several package tasks in other
projects, each of which create a zip or jar.
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.
So I tried to get my master 'build' task to depend on the other
packages. It wouldn't be ideal, because sometimes I would just want to
build enough to test, and other times I would want to take the extra
time (and prompt the user for passwords) required to create signed jars.
But I would take a master build task for now, as a starting point.
So far, that hasn't worked either. Here was my latest failed attempt,
inside the definition of my master project:
build do
jar = project('utils').package(:jar)
unzip(_('target/utils')=>jar)
end
As far as I can tell, it had no effect whatsoever (no errors either).
Would I have to define 'install' tasks in my non-master projects? If so,
could I automatically invoke them from master:build? It seems wrong to
run master:install to get all the other project artifacts in place, and
then do a master:build after that do pull them all into _('target').
Kevin
Re: New buildr user questions
Posted by Antoine Toulme <an...@lunar-ocean.com>.
On Tue, Feb 9, 2010 at 17:05, Kevin Smith <ke...@qualitycode.com> wrote:
> Greetings all,
>
> First, let me say that I am generally happy with buildr. I'm a long-time
> ruby user and XML hater, so having an alternative to ant/maven is great.
> I have managed to get most of my build system working, but have several
> problems/questions. If any of these are answered in the online docs,
> wiki, jira, or mailing list archives, feel free to just point me in that
> direction.
>
> 1. How to extract a file from an artifact?
>
> I need to extract the license file out of some third-party jar
> artifacts. I can't find any easy way to do that. The best I have come up
> with is to create a zip task that includes the artifact. Then, turn
> around and unzip the zip, then unzip the jar. Yuck.
>
You can declare a unzip task, and build it:
build unzip(_("target/jetty")=>artifact(JETTY))
>
> 2. How to copy artifact files?
>
> This is closely related to #1. My script creates an ISO image. I would
> like to simply copy some artifacts into the ISO directory, but don't see
> any way to do it. My workaround is to create a zip containing the full
> directory structure I want, and then unzipping it into the ISO image.
> Seems like it should be easier.
>
Well, that's pure Ruby, off the top of my head:
cp a z
>
> 3. How to specify a dependency for a package task?
>
> Several times, I have wanted to specify that the package task for a
> project should depend on some other task. In one case, I had a master
> project and several related projects (which were not buildr subprojects
> because I couldn't get those to work the way I wanted). I simply wanted
> to create a 'package' target in the master project, which depends on the
> package targets of the other projects. I can see how to do this for
> 'build', but not for 'package'.
>
You use the enhance method that takes an array as argument:
package(:zip).enhance [task1, task2]
>
> Kevin
>
>
>