You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Assaf Arkin <ar...@intalio.com> on 2008/05/02 01:49:21 UTC
Buildr 1.3 is out!
New and improved in 1.3:
Support for multiple languages, not just Java. 1.3 adds support for
compiling and testing Groovy and Scala projects, and a new API if you want
to go and add support for any other language.
You can also test your Java/Groovy/Scala project using Ruby and the RSpec
framework (requires JRuby).
Speaking of JRuby: yes. Buildr now runs on JRuby, 1.1 or later. The JVM is
a bit slow to startup, so we also got Nailgun server support.
JRuby and RJB have different ways to access Java classes, JRuby's is nicer
so we wrote a little adapter to make RJB work like JRuby (if you're not
using JRuby, then you're using RJB).
Besides JUnit and TestNG, we got three BDD (Behavior-Driven Development)
frameworks: JBehave, RSpec and EasyB.
RSpec is the one we use for Buildr itself. Besides running the entire test
suite, we also use it to document the official Buildr specification, which
we keep updated on the Web site.
We've got support for EAR packaging, and also packaging of files in addition
to artifacts.
New to this release is build.yaml that you can use alongside the buildfile
to specify things like remote repositories, addons, artifacts, etc. There's
also a settings.yaml that belongs in your home .buildr directory. We'll be
adding more features that use these two in upcoming releases.
And speaking of addons, first we have a cleaner API for writing extensions.
And, we played around with different options, only to realize the easiest
way to package and distribute addons is in the form of Ruby Gems. So 1.3
provides a way to list these gems in build.yaml and will download/install
them on request.
We have new guide for setting up Ruby/JRuby and Buildr, and two new sections
on the Web site, one with common recipes for using Buildr, the other for
troubleshooting and workarounds, both collected from the mailing list/JIRA.
For everything that's new in 1.3, with more details than I can provide here,
head over to the what's new page:
http://incubator.apache.org/buildr/whats_new.html
And last but not least, thanks to all of your for making this happen, and
putting up with the delay.
Assaf
PS We have two broken links on the site, I'm working on fixing those.
Re: Buildr 1.3 is out!
Posted by Assaf Arkin <ar...@intalio.com>.
On Thu, May 1, 2008 at 4:55 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> Congratulations on the release!
>
> Regarding the settings files (e.g. build.yaml), does the ".yml" extension
> work as well? As far as I know, most uses of the YAML format use this
> extension rather than the full "yaml" (e.g. database.yml in Rails).
Yes, either one will work (although I forgot to add a test case for both,
will do promptly).
Assaf
>
>
> Daniel
>
> On Thu, May 1, 2008 at 6:49 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> > New and improved in 1.3:
> >
> > Support for multiple languages, not just Java. 1.3 adds support for
> > compiling and testing Groovy and Scala projects, and a new API if you
> want
> > to go and add support for any other language.
> >
> > You can also test your Java/Groovy/Scala project using Ruby and the RSpec
> > framework (requires JRuby).
> >
> > Speaking of JRuby: yes. Buildr now runs on JRuby, 1.1 or later. The JVM
> > is
> > a bit slow to startup, so we also got Nailgun server support.
> >
> > JRuby and RJB have different ways to access Java classes, JRuby's is
> nicer
> > so we wrote a little adapter to make RJB work like JRuby (if you're not
> > using JRuby, then you're using RJB).
> >
> > Besides JUnit and TestNG, we got three BDD (Behavior-Driven Development)
> > frameworks: JBehave, RSpec and EasyB.
> >
> > RSpec is the one we use for Buildr itself. Besides running the entire
> > test
> > suite, we also use it to document the official Buildr specification,
> which
> > we keep updated on the Web site.
> >
> > We've got support for EAR packaging, and also packaging of files in
> > addition
> > to artifacts.
> >
> > New to this release is build.yaml that you can use alongside the
> buildfile
> > to specify things like remote repositories, addons, artifacts, etc.
> > There's
> > also a settings.yaml that belongs in your home .buildr directory. We'll
> > be
> > adding more features that use these two in upcoming releases.
> >
> > And speaking of addons, first we have a cleaner API for writing
> > extensions.
> > And, we played around with different options, only to realize the
> easiest
> > way to package and distribute addons is in the form of Ruby Gems. So 1.3
> > provides a way to list these gems in build.yaml and will download/install
> > them on request.
> >
> > We have new guide for setting up Ruby/JRuby and Buildr, and two new
> > sections
> > on the Web site, one with common recipes for using Buildr, the other for
> > troubleshooting and workarounds, both collected from the mailing
> > list/JIRA.
> >
> > For everything that's new in 1.3, with more details than I can provide
> > here,
> > head over to the what's new page:
> >
> > http://incubator.apache.org/buildr/whats_new.html
> >
> > And last but not least, thanks to all of your for making this happen, and
> > putting up with the delay.
> >
> > Assaf
> >
> >
> > PS We have two broken links on the site, I'm working on fixing those.
> >
>
Re: Buildr 1.3 is out!
Posted by Daniel Spiewak <dj...@gmail.com>.
Congratulations on the release!
Regarding the settings files (e.g. build.yaml), does the ".yml" extension
work as well? As far as I know, most uses of the YAML format use this
extension rather than the full "yaml" (e.g. database.yml in Rails).
Daniel
On Thu, May 1, 2008 at 6:49 PM, Assaf Arkin <ar...@intalio.com> wrote:
> New and improved in 1.3:
>
> Support for multiple languages, not just Java. 1.3 adds support for
> compiling and testing Groovy and Scala projects, and a new API if you want
> to go and add support for any other language.
>
> You can also test your Java/Groovy/Scala project using Ruby and the RSpec
> framework (requires JRuby).
>
> Speaking of JRuby: yes. Buildr now runs on JRuby, 1.1 or later. The JVM
> is
> a bit slow to startup, so we also got Nailgun server support.
>
> JRuby and RJB have different ways to access Java classes, JRuby's is nicer
> so we wrote a little adapter to make RJB work like JRuby (if you're not
> using JRuby, then you're using RJB).
>
> Besides JUnit and TestNG, we got three BDD (Behavior-Driven Development)
> frameworks: JBehave, RSpec and EasyB.
>
> RSpec is the one we use for Buildr itself. Besides running the entire
> test
> suite, we also use it to document the official Buildr specification, which
> we keep updated on the Web site.
>
> We've got support for EAR packaging, and also packaging of files in
> addition
> to artifacts.
>
> New to this release is build.yaml that you can use alongside the buildfile
> to specify things like remote repositories, addons, artifacts, etc.
> There's
> also a settings.yaml that belongs in your home .buildr directory. We'll
> be
> adding more features that use these two in upcoming releases.
>
> And speaking of addons, first we have a cleaner API for writing
> extensions.
> And, we played around with different options, only to realize the easiest
> way to package and distribute addons is in the form of Ruby Gems. So 1.3
> provides a way to list these gems in build.yaml and will download/install
> them on request.
>
> We have new guide for setting up Ruby/JRuby and Buildr, and two new
> sections
> on the Web site, one with common recipes for using Buildr, the other for
> troubleshooting and workarounds, both collected from the mailing
> list/JIRA.
>
> For everything that's new in 1.3, with more details than I can provide
> here,
> head over to the what's new page:
>
> http://incubator.apache.org/buildr/whats_new.html
>
> And last but not least, thanks to all of your for making this happen, and
> putting up with the delay.
>
> Assaf
>
>
> PS We have two broken links on the site, I'm working on fixing those.
>
Re: Buildr 1.3 is out!
Posted by Assaf Arkin <ar...@intalio.com>.
On Wed, May 7, 2008 at 1:10 PM, Stephen Bannasch <
stephen.bannasch@deanbrook.org> wrote:
> At 4:49 PM -0700 5/1/08, Assaf Arkin wrote:
> >New and improved in 1.3:
>
> Looks great.
>
> One comments regarding using it with jruby. This page:
>
> http://incubator.apache.org/buildr/getting_started.html#jruby
>
> starts by suggesting adding the path to JRuby's bin/ dir to the end of the
> path and executing:
>
> gem install buildr
Good point. We need to fix these examples. The second part if you read
down actually deals with all these issues, talk about -S and how to set the
path properly (JRuby first if it's your preferred runtime), but the examples
in the first part apparently didn't read about the second part :-)
Assaf
>
>
> I'll bet that most of the OS systems that have JRuby installed already have
> Ruby installed and that the system app bin/ directories will already have a
> gem command installed there. In this case the gem install command will
> install buildr for the system Ruby (presumably MRI).
>
> I think you could simplify your instructions and lessen some users problems
> by telling people to always run a JRuby system script like gem with this
> form of the command:
>
> jruby -S gem install buildr
>
> This should always work. This form is recommended in the JRuby wiki getting
> started page:
>
>
> http://wiki.jruby.org/wiki/Getting_Started#Invoking_system-level_executable_commands
>
> Background:
>
> Because rubgems doesn't have any explicit support for coordinating a gem
> repository for multiple Ruby VM installations on one system a number of
> people are having troubles when they inadvertently create a gem repository
> shared by MRI and JRuby.
>
> I recommend always using separate gem, lib/, and bin/ locations for a JRuby
> install and always running JRuby versions of the Ruby system commands with
> the 'jruby -S' prologue. Getting into this habit helps people differentiate
> when they are running JRuby instead of Ruby.
>
> There have been some recent inconclusive threads on the rubygems-dev list
> about these issues. The following is quoted from a recent post I made:
>
> >My suggestion below is based on the initial assumption that jruby (as an
> alternate ruby VM) is installed in a manner in which there are separate lib
> gem and bin directories from the standard system Ruby. In addition IF a path
> to JRUBY_HOME/bin is put on the PATH env variable it is only put after a
> path reference to any system Ruby and it's associated system bin/ directory.
> >
> >I haven't seen evidence that any other install strategy for an alternate
> Ruby VM will work. Nobody has yet described how a shared gem repository
> could work reliably when native code is involved under the current
> implementations.
> >
> >It is the responsibility of JRuby (and packagers of JRuby) to make this
> separation of gem, bin, and lib directories from any other installed Ruby VM
> the likely outcome of various install processes.
> >
> >Assuming an install as described above I suggest keeping the installed gem
> command as 'gem' for all alternate Ruby VMs and possibly adding a jgem
> command to the standard system location for bin commands. The jgem command
> would execute:
> >
> > /path/to/jruby/bin/jruby -S gem
> >
> >This way anytime you are expecting to be using MRI (or another standard
> system Ruby VM) typing gem will do what you expect.
> >
> >To run the JRuby gem you can type:
> >
> > jgem
> >
> >OR if you have added JRUBY_HOME/bin to your path you can also type:
> >
> > jruby -S gem
> >
> >If my conclusion about keeping separate gem, bin, and lib directories is
> correct for alternate Ruby VMs AND the actual installation of multiple Ruby
> VMs on multiple platforms can be introspected in a reliable way THEN it
> **might** be useful for RubyGems to refuse to upgrade itself or install a
> gem in a mixed repository without using some type of --force parameter.
>
>
> References:
>
> http://rubyforge.org/pipermail/rubygems-developers/2008-April/003691.html
> http://rubyforge.org/pipermail/rubygems-developers/2008-April/003777.html
>
--
CTO, Intalio
http://www.intalio.com
Re: Buildr 1.3 is out!
Posted by Stephen Bannasch <st...@deanbrook.org>.
At 4:49 PM -0700 5/1/08, Assaf Arkin wrote:
>New and improved in 1.3:
Looks great.
One comments regarding using it with jruby. This page:
http://incubator.apache.org/buildr/getting_started.html#jruby
starts by suggesting adding the path to JRuby's bin/ dir to the end of the path and executing:
gem install buildr
I'll bet that most of the OS systems that have JRuby installed already have Ruby installed and that the system app bin/ directories will already have a gem command installed there. In this case the gem install command will install buildr for the system Ruby (presumably MRI).
I think you could simplify your instructions and lessen some users problems by telling people to always run a JRuby system script like gem with this form of the command:
jruby -S gem install buildr
This should always work. This form is recommended in the JRuby wiki getting started page:
http://wiki.jruby.org/wiki/Getting_Started#Invoking_system-level_executable_commands
Background:
Because rubgems doesn't have any explicit support for coordinating a gem repository for multiple Ruby VM installations on one system a number of people are having troubles when they inadvertently create a gem repository shared by MRI and JRuby.
I recommend always using separate gem, lib/, and bin/ locations for a JRuby install and always running JRuby versions of the Ruby system commands with the 'jruby -S' prologue. Getting into this habit helps people differentiate when they are running JRuby instead of Ruby.
There have been some recent inconclusive threads on the rubygems-dev list about these issues. The following is quoted from a recent post I made:
>My suggestion below is based on the initial assumption that jruby (as an alternate ruby VM) is installed in a manner in which there are separate lib gem and bin directories from the standard system Ruby. In addition IF a path to JRUBY_HOME/bin is put on the PATH env variable it is only put after a path reference to any system Ruby and it's associated system bin/ directory.
>
>I haven't seen evidence that any other install strategy for an alternate Ruby VM will work. Nobody has yet described how a shared gem repository could work reliably when native code is involved under the current implementations.
>
>It is the responsibility of JRuby (and packagers of JRuby) to make this separation of gem, bin, and lib directories from any other installed Ruby VM the likely outcome of various install processes.
>
>Assuming an install as described above I suggest keeping the installed gem command as 'gem' for all alternate Ruby VMs and possibly adding a jgem command to the standard system location for bin commands. The jgem command would execute:
>
> /path/to/jruby/bin/jruby -S gem
>
>This way anytime you are expecting to be using MRI (or another standard system Ruby VM) typing gem will do what you expect.
>
>To run the JRuby gem you can type:
>
> jgem
>
>OR if you have added JRUBY_HOME/bin to your path you can also type:
>
> jruby -S gem
>
>If my conclusion about keeping separate gem, bin, and lib directories is correct for alternate Ruby VMs AND the actual installation of multiple Ruby VMs on multiple platforms can be introspected in a reliable way THEN it **might** be useful for RubyGems to refuse to upgrade itself or install a gem in a mixed repository without using some type of --force parameter.
References:
http://rubyforge.org/pipermail/rubygems-developers/2008-April/003691.html
http://rubyforge.org/pipermail/rubygems-developers/2008-April/003777.html
Re: Buildr 1.3 is out!
Posted by Tal Rotbart <re...@gmail.com>.
You guys rock my socks!
Thanks for a wonderful build system that takes the pain away.
Cheers,
Tal
On Fri, May 2, 2008 at 10:43 AM, Alex Boisvert <bo...@intalio.com> wrote:
> Congrats to the dev team and a special thanks to Assaf for taking on the
> release management role! The first Apache release is the hardest :)
>
> alex
>
>
>
> On Thu, May 1, 2008 at 4:49 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
>
>
> > New and improved in 1.3:
> >
> > Support for multiple languages, not just Java. 1.3 adds support for
> > compiling and testing Groovy and Scala projects, and a new API if you want
> > to go and add support for any other language.
> >
> > You can also test your Java/Groovy/Scala project using Ruby and the RSpec
> > framework (requires JRuby).
> >
> > Speaking of JRuby: yes. Buildr now runs on JRuby, 1.1 or later. The JVM
> > is
> > a bit slow to startup, so we also got Nailgun server support.
> >
> > JRuby and RJB have different ways to access Java classes, JRuby's is nicer
> > so we wrote a little adapter to make RJB work like JRuby (if you're not
> > using JRuby, then you're using RJB).
> >
> > Besides JUnit and TestNG, we got three BDD (Behavior-Driven Development)
> > frameworks: JBehave, RSpec and EasyB.
> >
> > RSpec is the one we use for Buildr itself. Besides running the entire
> > test
> > suite, we also use it to document the official Buildr specification, which
> > we keep updated on the Web site.
> >
> > We've got support for EAR packaging, and also packaging of files in
> > addition
> > to artifacts.
> >
> > New to this release is build.yaml that you can use alongside the buildfile
> > to specify things like remote repositories, addons, artifacts, etc.
> > There's
> > also a settings.yaml that belongs in your home .buildr directory. We'll
> > be
> > adding more features that use these two in upcoming releases.
> >
> > And speaking of addons, first we have a cleaner API for writing
> > extensions.
> > And, we played around with different options, only to realize the easiest
> > way to package and distribute addons is in the form of Ruby Gems. So 1.3
> > provides a way to list these gems in build.yaml and will download/install
> > them on request.
> >
> > We have new guide for setting up Ruby/JRuby and Buildr, and two new
> > sections
> > on the Web site, one with common recipes for using Buildr, the other for
> > troubleshooting and workarounds, both collected from the mailing
> > list/JIRA.
> >
> > For everything that's new in 1.3, with more details than I can provide
> > here,
> > head over to the what's new page:
> >
> > http://incubator.apache.org/buildr/whats_new.html
> >
> > And last but not least, thanks to all of your for making this happen, and
> > putting up with the delay.
> >
> > Assaf
> >
> >
> > PS We have two broken links on the site, I'm working on fixing those.
> >
>
Re: Buildr 1.3 is out!
Posted by Alex Boisvert <bo...@intalio.com>.
Congrats to the dev team and a special thanks to Assaf for taking on the
release management role! The first Apache release is the hardest :)
alex
On Thu, May 1, 2008 at 4:49 PM, Assaf Arkin <ar...@intalio.com> wrote:
> New and improved in 1.3:
>
> Support for multiple languages, not just Java. 1.3 adds support for
> compiling and testing Groovy and Scala projects, and a new API if you want
> to go and add support for any other language.
>
> You can also test your Java/Groovy/Scala project using Ruby and the RSpec
> framework (requires JRuby).
>
> Speaking of JRuby: yes. Buildr now runs on JRuby, 1.1 or later. The JVM
> is
> a bit slow to startup, so we also got Nailgun server support.
>
> JRuby and RJB have different ways to access Java classes, JRuby's is nicer
> so we wrote a little adapter to make RJB work like JRuby (if you're not
> using JRuby, then you're using RJB).
>
> Besides JUnit and TestNG, we got three BDD (Behavior-Driven Development)
> frameworks: JBehave, RSpec and EasyB.
>
> RSpec is the one we use for Buildr itself. Besides running the entire
> test
> suite, we also use it to document the official Buildr specification, which
> we keep updated on the Web site.
>
> We've got support for EAR packaging, and also packaging of files in
> addition
> to artifacts.
>
> New to this release is build.yaml that you can use alongside the buildfile
> to specify things like remote repositories, addons, artifacts, etc.
> There's
> also a settings.yaml that belongs in your home .buildr directory. We'll
> be
> adding more features that use these two in upcoming releases.
>
> And speaking of addons, first we have a cleaner API for writing
> extensions.
> And, we played around with different options, only to realize the easiest
> way to package and distribute addons is in the form of Ruby Gems. So 1.3
> provides a way to list these gems in build.yaml and will download/install
> them on request.
>
> We have new guide for setting up Ruby/JRuby and Buildr, and two new
> sections
> on the Web site, one with common recipes for using Buildr, the other for
> troubleshooting and workarounds, both collected from the mailing
> list/JIRA.
>
> For everything that's new in 1.3, with more details than I can provide
> here,
> head over to the what's new page:
>
> http://incubator.apache.org/buildr/whats_new.html
>
> And last but not least, thanks to all of your for making this happen, and
> putting up with the delay.
>
> Assaf
>
>
> PS We have two broken links on the site, I'm working on fixing those.
>