>> 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
