You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Peter Donald <pe...@realityforge.org> on 2010/03/28 23:52:16 UTC
External extensions use of buildr test infrastructure
Hi,
I am currently playing with a few different buildr extensions and I
desire to make use of the test infrastructure part of buildr proper.
What is the typical approach to doing this sort of thing? Currently I
have gone with adding something like the following into my spec_helper
/ test_helper
------------------------------------------------------------------------------------------------
# TODO: If we are installed as a gem we should just add dependency on
buildr gem and find dir based on that
DEFAULT_BUILDR_DIR=File.expand_path(File.dirname(__FILE__) + '/../../buildr')
BUILDR_DIR=ENV['BUILDR_DIR'] || DEFAULT_BUILDR_DIR
unless File.exist?("#{BUILDR_DIR}/buildr.gemspec")
raise "Unable to find buildr.gemspec in #{BUILDR_DIR ==
DEFAULT_BUILDR_DIR ? 'guessed' : 'specified'} $BUILD_DIR
(#{BUILDR_DIR})"
end
require 'rubygems'
# For testing we use the gem requirements specified on the buildr.gemspec
Gem::Specification.load(File.expand_path("#{BUILDR_DIR}/buildr.gemspec",
File.dirname(__FILE__))).
dependencies.each { |dep| gem dep.name, dep.requirement.to_s }
------------------------------------------------------------------------------------------------
Then depending on what types of tests I am running adding something
like the following a bit later.
require "#{BUILDR_DIR}/spec/spec_helpers.rb"
You can see an example in
http://github.com/rockninja/buildr-iidea/blob/master/spec/spec_helper.rb
My main goal is to be able to test the plugin against trunk buildr and
against the last release. Down the track I will also want it to work
if/when the extension is released as a gem.
So has anyone got a recommend approach to do this sort of thing? Is
what I am doing the right way of doing things or am I going to run
into issues?
--
Cheers,
Peter Donald
Re: External extensions use of buildr test infrastructure
Posted by Peter Donald <pe...@realityforge.org>.
>> Thats similar to how I had been doing it but because I actually use
>> piston [1] to import the plugins into a subversion repo I was ending
>> up with 4 copies of buildr code in subversion (one for each of the
>> three plugins and one for buildr). This was my motivation to removing
>> buildr from the vendor dir of every plugin I was working on.
>>
>
> If I'm understanding you correctly, one option to prevent this would be packaging the extension as a gem. Then it could be installed once for the whole system instead of being inlined in the subversion repo.
The specific scenario that I am facing occurs when i have plugins A, B
and C included in multiple projects and under active development. I
want each project to be able to be built and tested with a specific
version. I also intent to use a specific version of buildr down the
track in some of the projects (right now I am testing the plugins
against both trunk and the released versions of buildr). The way I
have been doing this is something along the lines of
$ mkdir vendor/buildr
$ piston import git://github.com/someone/buildr-a.git vendor/buildr/buildr-a
$ piston import git://github.com/someone/buildr-b.git vendor/buildr/buildr-b
$ piston import git://github.com/someone/buildr-c.git vendor/buildr/buildr-c
$ piston import git://git.apache.org/buildr.git vendor/buildr/buildr
I want to do it this way as I can test the project against specific
versions of plugins/extensions and ensure that it will build
correctly. I could check in expanded versions of gems but this makes
it a little more painful to update the plugins. With piston I can just
update the plugin in its own repo and do something like
$ piston update vendor/buildr/buildr-a
to get the most recent version of the plugin.
The approach of placing a copy of buildr in vendor/ dir in each plugin
meant that each plugin was testing against a potentially different
version of buildr and there was multiple copies of buildr in each
project that used these plugins.
--
Cheers,
Peter Donald
Re: External extensions use of buildr test infrastructure
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Peter,
On Mar 28, 2010, at 5:48 PM, Peter Donald wrote:
>> Look at Buildr4OSGi and the SandBoxHook module to see how I do it. I use
>> braid to have something that looks like a svn:externals checkout of the
>> Buildr code.
>
> Ok.
>
> Thats similar to how I had been doing it but because I actually use
> piston [1] to import the plugins into a subversion repo I was ending
> up with 4 copies of buildr code in subversion (one for each of the
> three plugins and one for buildr). This was my motivation to removing
> buildr from the vendor dir of every plugin I was working on.
>
If I'm understanding you correctly, one option to prevent this would be packaging the extension as a gem. Then it could be installed once for the whole system instead of being inlined in the subversion repo.
Rhett
> [1] http://piston.rubyforge.org/
>
> --
> Cheers,
>
> Peter Donald
Re: External extensions use of buildr test infrastructure
Posted by Peter Donald <pe...@realityforge.org>.
> Look at Buildr4OSGi and the SandBoxHook module to see how I do it. I use
> braid to have something that looks like a svn:externals checkout of the
> Buildr code.
Ok.
Thats similar to how I had been doing it but because I actually use
piston [1] to import the plugins into a subversion repo I was ending
up with 4 copies of buildr code in subversion (one for each of the
three plugins and one for buildr). This was my motivation to removing
buildr from the vendor dir of every plugin I was working on.
[1] http://piston.rubyforge.org/
--
Cheers,
Peter Donald
Re: External extensions use of buildr test infrastructure
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Look at Buildr4OSGi and the SandBoxHook module to see how I do it. I use
braid to have something that looks like a svn:externals checkout of the
Buildr code.
On my blog, back in September, I gave steps on how to do this:
http://www.lunar-ocean.com/how-to-create-a-plugin-for-buildr/
On Sun, Mar 28, 2010 at 14:52, Peter Donald <pe...@realityforge.org> wrote:
> Hi,
>
> I am currently playing with a few different buildr extensions and I
> desire to make use of the test infrastructure part of buildr proper.
> What is the typical approach to doing this sort of thing? Currently I
> have gone with adding something like the following into my spec_helper
> / test_helper
>
>
> ------------------------------------------------------------------------------------------------
> # TODO: If we are installed as a gem we should just add dependency on
> buildr gem and find dir based on that
> DEFAULT_BUILDR_DIR=File.expand_path(File.dirname(__FILE__) +
> '/../../buildr')
> BUILDR_DIR=ENV['BUILDR_DIR'] || DEFAULT_BUILDR_DIR
>
> unless File.exist?("#{BUILDR_DIR}/buildr.gemspec")
> raise "Unable to find buildr.gemspec in #{BUILDR_DIR ==
> DEFAULT_BUILDR_DIR ? 'guessed' : 'specified'} $BUILD_DIR
> (#{BUILDR_DIR})"
> end
>
> require 'rubygems'
>
> # For testing we use the gem requirements specified on the buildr.gemspec
> Gem::Specification.load(File.expand_path("#{BUILDR_DIR}/buildr.gemspec",
> File.dirname(__FILE__))).
> dependencies.each { |dep| gem dep.name, dep.requirement.to_s }
>
> ------------------------------------------------------------------------------------------------
>
> Then depending on what types of tests I am running adding something
> like the following a bit later.
>
> require "#{BUILDR_DIR}/spec/spec_helpers.rb"
>
> You can see an example in
> http://github.com/rockninja/buildr-iidea/blob/master/spec/spec_helper.rb
>
> My main goal is to be able to test the plugin against trunk buildr and
> against the last release. Down the track I will also want it to work
> if/when the extension is released as a gem.
>
> So has anyone got a recommend approach to do this sort of thing? Is
> what I am doing the right way of doing things or am I going to run
> into issues?
>
> --
> Cheers,
>
> Peter Donald
>