views:

16

answers:

2

I am currently looking at migrating from maven2 to buildr and I am concerned about how get to keep the build scripts DRY.

Currently our maven project is defined with parent pom file containing all common build code and is picked up like any other dependency:

<parent>
    <groupId>com.companyname</groupid>
    <artifactId>parent</artifactId>
    <version>1.0.0</artifactId>
</parent>

Now I am looking at buildr and I notice that it does have a simular concept but it would require placing a buildfile one level-up, for example:

/svnrepo/buildfile
/svnrepo/ProjectA
/svnrepo/ProjectB

This is a problem however because these projects are not related and will be checked out and build totally separately. So my question is: how do I best solve this problem? How do I reference a common buildfile while being able to checkout only one project at a time?

A: 

I think you are confused:

on one hand, your projects are right now built together with Maven, with 4 different repositories that you check out in the right places or use svn:externals. That sounds like a bad idea.

On the other hand, you want to do the same thing with Buildr, but are concerned it's not going to look good ?

Please build those projects separately indeed! If you have code that can be reused from a project to another, like a custom task, then use a svn:externals in each project pointing to a ruby file that the buildfile requires.

Antoine Toulme
They are all separate, unrelated projects that we build separately. But there is always going to be common tasks that we want to share across projects (static analysis tools, deployment tasks etc). I could use svn:externals but I was hoping to avoid this because it is generally bad practice: http://bit.ly/9wN9yk
liam.j.bennett
I find myself disagreeing with most of the points made in the blog above. Equivalent solutions exists in other SCM tools to achieve the same as SVN externals. And some of the points are not relevant, since this is precisely about sharing scripting code between projects.In any case, sounds like you found a solution you like, so that's the important thing.
Alex Boisvert
A: 

I discovered the answer to this problem and I am kicking myself about how easy it is: create a gem.

replace parent-pom.xml with parent.rb and distribute the ruby file as a gem to be required by all other projects.

liam.j.bennett
Another alternative that many people use is to share file(s) through the version control system using features such as SVN externals, Git submodules, Git braids, etc. This approach alleviates the need to package and deploy a gem.
Alex Boisvert