tag:old.nabble.com,2006:forum-28729Nabble - Buildr2009-11-27T00:44:54Z<a href="http://incubator.apache.org/projects/buildr.html" target="_top" rel="nofollow">Buildr</a> is a build system for Java applications written in Ruby. We wanted something that's simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that?s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management.tag:old.nabble.com,2006:post-26537708Including dependencies with a JAR package2009-11-27T00:44:54Z2009-11-27T00:44:54ZtommycliI use buildr with the transitive compile.with artifact specifications.
<br><br>My problem is this: After buildr makes its package, I have a nice JAR file, but I cannot run it without its dependency JARs.
<br><br>I don't even know which JARs it depends on. How do you find out which JARs you need to distribute with your project? Can buildr package all of it into one file?
<br><br>Tommy<p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-26292941Re: Bundled Buildr + JRuby distribution2009-11-10T14:59:29Z2009-11-10T14:59:29ZAlex BoisvertThanks, yes, I think I have solutions for both platforms now. Just need to
<br>start VirtualBox to test the Windows part (which I should have done the
<br>first time around).
<br><br>And I've now removed all other scripts (jirb, jrubyc, ...) so they don't
<br>conflict with other JRuby installs.
<br><br>alex
<br><br><br>On Tue, Nov 10, 2009 at 2:53 PM, Nick Sieger <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292941&i=0" target="_top" rel="nofollow">nicksieger@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Alex,
<br>>
<br>> For Windows, you can piggy back off our new native launcher in JRuby 1.4 by
<br>> copying jruby.exe to buildr.exe. This effectively does the same as "jruby -S
<br>> buildr" would do. The PATH issue is trickier admittedly. You really need the
<br>> shebang in the "buildr" script to point to the copy of JRuby that was
<br>> bundled, instead of "#!/usr/bin/env jruby".
<br>>
<br>> /Nick
<br>>
<br>>
<br>> On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:
<br>>
<br>> Hmmmm.... for a start there's two big issues with this distro. First, if
<br>>> you already have jruby in your PATH, things get confused and basically
<br>>> nothing works. Second, there's no buildr.bat so it's pretty useless for
<br>>> Windows users. (Unless they are willing to run "jruby -S buildr")
<br>>>
<br>>> I'll do another take later. Thanks for listening ;)
<br>>>
<br>>> alex
<br>>>
<br>>>
<br>>> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292941&i=1" target="_top" rel="nofollow">alex.boisvert@...</a>
<br>>> >wrote:
<br>>>
<br>>> Hi,
<br>>>>
<br>>>> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>>>> and made it available at:
<br>>>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>>> <<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>>>
<br>>>>
<br>>>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>>>> everything I could that didn't affect functionality, such as
<br>>>> documentation
<br>>>> and Ruby 1.9 support.
<br>>>>
<br>>>> To use it, simply
<br>>>> 1) unzip in a directory,
<br>>>> 2) set your PATH to point to the "bin" directory, and
<br>>>> 3) run "buildr" as usual.
<br>>>>
<br>>>> Looking for feedback on how it works as a quick way to get yourself/other
<br>>>> people started. If there's enough interest, it could become part of our
<br>>>> supported distros.
<br>>>>
<br>>>> thanks,
<br>>>> alex
<br>>>>
<br>>>>
<br>>>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-26292942Re: Bundled Buildr + JRuby distribution2009-11-10T14:59:29Z2009-11-10T14:59:29ZAlex BoisvertThanks, yes, I think I have solutions for both platforms now. Just need to
<br>start VirtualBox to test the Windows part (which I should have done the
<br>first time around).
<br><br>And I've now removed all other scripts (jirb, jrubyc, ...) so they don't
<br>conflict with other JRuby installs.
<br><br>alex
<br><br><br>On Tue, Nov 10, 2009 at 2:53 PM, Nick Sieger <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292942&i=0" target="_top" rel="nofollow">nicksieger@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Alex,
<br>>
<br>> For Windows, you can piggy back off our new native launcher in JRuby 1.4 by
<br>> copying jruby.exe to buildr.exe. This effectively does the same as "jruby -S
<br>> buildr" would do. The PATH issue is trickier admittedly. You really need the
<br>> shebang in the "buildr" script to point to the copy of JRuby that was
<br>> bundled, instead of "#!/usr/bin/env jruby".
<br>>
<br>> /Nick
<br>>
<br>>
<br>> On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:
<br>>
<br>> Hmmmm.... for a start there's two big issues with this distro. First, if
<br>>> you already have jruby in your PATH, things get confused and basically
<br>>> nothing works. Second, there's no buildr.bat so it's pretty useless for
<br>>> Windows users. (Unless they are willing to run "jruby -S buildr")
<br>>>
<br>>> I'll do another take later. Thanks for listening ;)
<br>>>
<br>>> alex
<br>>>
<br>>>
<br>>> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292942&i=1" target="_top" rel="nofollow">alex.boisvert@...</a>
<br>>> >wrote:
<br>>>
<br>>> Hi,
<br>>>>
<br>>>> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>>>> and made it available at:
<br>>>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>>> <<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>>>
<br>>>>
<br>>>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>>>> everything I could that didn't affect functionality, such as
<br>>>> documentation
<br>>>> and Ruby 1.9 support.
<br>>>>
<br>>>> To use it, simply
<br>>>> 1) unzip in a directory,
<br>>>> 2) set your PATH to point to the "bin" directory, and
<br>>>> 3) run "buildr" as usual.
<br>>>>
<br>>>> Looking for feedback on how it works as a quick way to get yourself/other
<br>>>> people started. If there's enough interest, it could become part of our
<br>>>> supported distros.
<br>>>>
<br>>>> thanks,
<br>>>> alex
<br>>>>
<br>>>>
<br>>>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-26292839Re: Bundled Buildr + JRuby distribution2009-11-10T14:53:17Z2009-11-10T14:53:17ZNick Sieger-2Alex,
<br><br>For Windows, you can piggy back off our new native launcher in JRuby
<br>1.4 by copying jruby.exe to buildr.exe. This effectively does the same
<br>as "jruby -S buildr" would do. The PATH issue is trickier admittedly.
<br>You really need the shebang in the "buildr" script to point to the
<br>copy of JRuby that was bundled, instead of "#!/usr/bin/env jruby".
<br><br>/Nick
<br><br>On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:
<br><div class='shrinkable-quote'><br>> Hmmmm.... for a start there's two big issues with this distro.
<br>> First, if
<br>> you already have jruby in your PATH, things get confused and basically
<br>> nothing works. Second, there's no buildr.bat so it's pretty useless
<br>> for
<br>> Windows users. (Unless they are willing to run "jruby -S buildr")
<br>>
<br>> I'll do another take later. Thanks for listening ;)
<br>>
<br>> alex
<br>>
<br>>
<br>> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292839&i=0" target="_top" rel="nofollow">alex.boisvert@...</a>
<br>> >wrote:
<br>>
<br>>> Hi,
<br>>>
<br>>> I've created an experimental distribution of Buildr 1.3.5 and JRuby
<br>>> 1.4.0
<br>>> and made it available at:
<br>>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>
<br>>> >
<br>>>
<br>>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>>> everything I could that didn't affect functionality, such as
<br>>> documentation
<br>>> and Ruby 1.9 support.
<br>>>
<br>>> To use it, simply
<br>>> 1) unzip in a directory,
<br>>> 2) set your PATH to point to the "bin" directory, and
<br>>> 3) run "buildr" as usual.
<br>>>
<br>>> Looking for feedback on how it works as a quick way to get yourself/
<br>>> other
<br>>> people started. If there's enough interest, it could become part
<br>>> of our
<br>>> supported distros.
<br>>>
<br>>> thanks,
<br>>> alex
<br>>>
<br>>>
</div><br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-26292840Re: Bundled Buildr + JRuby distribution2009-11-10T14:53:17Z2009-11-10T14:53:17ZNick Sieger-2Alex,
<br><br>For Windows, you can piggy back off our new native launcher in JRuby
<br>1.4 by copying jruby.exe to buildr.exe. This effectively does the same
<br>as "jruby -S buildr" would do. The PATH issue is trickier admittedly.
<br>You really need the shebang in the "buildr" script to point to the
<br>copy of JRuby that was bundled, instead of "#!/usr/bin/env jruby".
<br><br>/Nick
<br><br>On Nov 10, 2009, at 16:42 , Alex Boisvert wrote:
<br><div class='shrinkable-quote'><br>> Hmmmm.... for a start there's two big issues with this distro.
<br>> First, if
<br>> you already have jruby in your PATH, things get confused and basically
<br>> nothing works. Second, there's no buildr.bat so it's pretty useless
<br>> for
<br>> Windows users. (Unless they are willing to run "jruby -S buildr")
<br>>
<br>> I'll do another take later. Thanks for listening ;)
<br>>
<br>> alex
<br>>
<br>>
<br>> On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292840&i=0" target="_top" rel="nofollow">alex.boisvert@...</a>
<br>> >wrote:
<br>>
<br>>> Hi,
<br>>>
<br>>> I've created an experimental distribution of Buildr 1.3.5 and JRuby
<br>>> 1.4.0
<br>>> and made it available at:
<br>>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>
<br>>> >
<br>>>
<br>>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>>> everything I could that didn't affect functionality, such as
<br>>> documentation
<br>>> and Ruby 1.9 support.
<br>>>
<br>>> To use it, simply
<br>>> 1) unzip in a directory,
<br>>> 2) set your PATH to point to the "bin" directory, and
<br>>> 3) run "buildr" as usual.
<br>>>
<br>>> Looking for feedback on how it works as a quick way to get yourself/
<br>>> other
<br>>> people started. If there's enough interest, it could become part
<br>>> of our
<br>>> supported distros.
<br>>>
<br>>> thanks,
<br>>> alex
<br>>>
<br>>>
</div><br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-26292698Re: Bundled Buildr + JRuby distribution2009-11-10T14:42:45Z2009-11-10T14:42:45ZAlex BoisvertHmmmm.... for a start there's two big issues with this distro. First, if
<br>you already have jruby in your PATH, things get confused and basically
<br>nothing works. Second, there's no buildr.bat so it's pretty useless for
<br>Windows users. (Unless they are willing to run "jruby -S buildr")
<br><br>I'll do another take later. Thanks for listening ;)
<br><br>alex
<br><br><br>On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292698&i=0" target="_top" rel="nofollow">alex.boisvert@...</a>>wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>> and made it available at:
<br>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>
<br>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>> everything I could that didn't affect functionality, such as documentation
<br>> and Ruby 1.9 support.
<br>>
<br>> To use it, simply
<br>> 1) unzip in a directory,
<br>> 2) set your PATH to point to the "bin" directory, and
<br>> 3) run "buildr" as usual.
<br>>
<br>> Looking for feedback on how it works as a quick way to get yourself/other
<br>> people started. If there's enough interest, it could become part of our
<br>> supported distros.
<br>>
<br>> thanks,
<br>> alex
<br>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-26292699Re: Bundled Buildr + JRuby distribution2009-11-10T14:42:45Z2009-11-10T14:42:45ZAlex BoisvertHmmmm.... for a start there's two big issues with this distro. First, if
<br>you already have jruby in your PATH, things get confused and basically
<br>nothing works. Second, there's no buildr.bat so it's pretty useless for
<br>Windows users. (Unless they are willing to run "jruby -S buildr")
<br><br>I'll do another take later. Thanks for listening ;)
<br><br>alex
<br><br><br>On Tue, Nov 10, 2009 at 2:04 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26292699&i=0" target="_top" rel="nofollow">alex.boisvert@...</a>>wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>> and made it available at:
<br>> <a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><<a href="http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip</a>>
<br>>
<br>> The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>> everything I could that didn't affect functionality, such as documentation
<br>> and Ruby 1.9 support.
<br>>
<br>> To use it, simply
<br>> 1) unzip in a directory,
<br>> 2) set your PATH to point to the "bin" directory, and
<br>> 3) run "buildr" as usual.
<br>>
<br>> Looking for feedback on how it works as a quick way to get yourself/other
<br>> people started. If there's enough interest, it could become part of our
<br>> supported distros.
<br>>
<br>> thanks,
<br>> alex
<br>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-26292098Bundled Buildr + JRuby distribution2009-11-10T14:04:19Z2009-11-10T14:04:19ZAlex BoisvertHi,
<br><br>I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>and made it available at:
<br><a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><br><br>The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>everything I could that didn't affect functionality, such as documentation
<br>and Ruby 1.9 support.
<br><br>To use it, simply
<br> 1) unzip in a directory,
<br> 2) set your PATH to point to the "bin" directory, and
<br> 3) run "buildr" as usual.
<br><br>Looking for feedback on how it works as a quick way to get yourself/other
<br>people started. If there's enough interest, it could become part of our
<br>supported distros.
<br><br>thanks,
<br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-26292099Bundled Buildr + JRuby distribution2009-11-10T14:04:19Z2009-11-10T14:04:19ZAlex BoisvertHi,
<br><br>I've created an experimental distribution of Buildr 1.3.5 and JRuby 1.4.0
<br>and made it available at:
<br><a href="http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip" target="_top" rel="nofollow">http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip</a><br><br>The distro is 15M -- not too bad. I've trimmed the packaged JRuby of
<br>everything I could that didn't affect functionality, such as documentation
<br>and Ruby 1.9 support.
<br><br>To use it, simply
<br> 1) unzip in a directory,
<br> 2) set your PATH to point to the "bin" directory, and
<br> 3) run "buildr" as usual.
<br><br>Looking for feedback on how it works as a quick way to get yourself/other
<br>people started. If there's enough interest, it could become part of our
<br>supported distros.
<br><br>thanks,
<br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-24286576Re: rspec - "Test framework error"2009-07-01T02:06:25Z2009-07-01T02:06:25ZdynnamittMore debug info:
<br><br>$ jruby -S buildr --version
<br>Buildr 1.3.4 (JRuby 1.3.0)
<br><br>I just found 2 tickets:
<br><a href="https://issues.apache.org/jira/browse/BUILDR-252" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/BUILDR-252</a><br><a href="https://issues.apache.org/jira/browse/BUILDR-254" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/BUILDR-254</a><br><br>Q1) Does this mean that RSpec support is not currently working ??
<br><br>Q2) Is it back to boring JUnit for me ?
<br><br>regards
<br>Dynnamitt
<br><br><br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">dynnamitt wrote:</div>
<div class="quote-message shrinkable-quote">when running :
<br>$ jruby -S buildr clean compile test --trace
<br>(Ubuntu 9.04)
<br><br>I get this trace:
<br>"
<br>Finished in 0.051 seconds
<br><br>0 examples, 0 failures
<br>Test framework error: No such file or directory - File not found - /java-app/target/spec/result.yaml
<br>/home/kdm/apps/jruby-1.3.0/lib/ruby/gems/1.8/gems/buildr-1.3.4-java/lib/buildr/java/bdd.rb:108:in `run'
<br>/home/kdm/apps/jruby-1.3.0/lib/ruby/gems/1.8/gems/buildr-1.3.4-java/lib/buildr/core/test.rb:446:in `run_tests' ......... etc etc etc
<br>"
<br><br><br>( I created one simple test spec at location: src/spec/ruby/jersey/test_spec.rb and it runs OK when using the spec app directly )
<br><br>What's up with this "result.yaml" missing in target ??
<br><br>regards
<br>Dynnamitt
</div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-24285950rspec - "Test framework error"2009-07-01T01:17:58Z2009-07-01T01:17:58Zdynnamittwhen running :
<br>$ jruby -S buildr clean compile test --trace
<br>(Ubuntu 9.04)
<br><br>I get this trace:
<br>"
<br>Finished in 0.051 seconds
<br><br>0 examples, 0 failures
<br>Test framework error: No such file or directory - File not found - /java-app/target/spec/result.yaml
<br>/home/kdm/apps/jruby-1.3.0/lib/ruby/gems/1.8/gems/buildr-1.3.4-java/lib/buildr/java/bdd.rb:108:in `run'
<br>/home/kdm/apps/jruby-1.3.0/lib/ruby/gems/1.8/gems/buildr-1.3.4-java/lib/buildr/core/test.rb:446:in `run_tests' ......... etc etc etc
<br>"
<br><br><br>( I created one simple test spec at location: src/spec/ruby/jersey/test_spec.rb and it runs OK when using the spec app directly )
<br><br>What's up with this "result.yaml" missing in target ??
<br><br>regards
<br>Dynnamitt
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-23845265Re: Building and testing Buildr plugins for profit2009-06-02T21:42:06Z2009-06-02T21:42:06ZIttay Dror<br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Antoine Toulme wrote:</div>
<div class="quote-message shrinkable-quote">Hi,
<br><br>while it's still fresh, I'd like to share the problems we encountered to
<br>build a plugin with Buildr.
<br><br>As you may know, Buildr is packaged as an application, so doing a require
<br>"buildr" brings quite a few things.
<br><br>In our case, we wanted to build a spec that was pretty much a copy/paste of
<br>javac.
<br><br>We tried first by requiring the gem and some of its modules. It turns out
<br>that there are a few clever tricks made in spec/spec_helpers.rb that are
<br>necessary to send rake tasks properly.
<br><br>In the end, we were able to test by placing buildr4eclipse along with
<br>buildr, and required the file explicitely.
<br>With that setup, tests are actually running in the buildr/tmp folder :-/. At
<br>least we could run the tests.
<br><br>There doesn't seem to be a way to require spec/spec_helpers.rb in the gem.
<br>The file is present in there though.
</div>
</div></blockquote>
can't you use:
<br>require 'buildr/../../spec/spec_helpers'
<br>?
<br><br>ittay
<br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-message shrinkable-quote">I am quite unsure there is a pleasant way to work around those problems. If
<br>the Buildr team is interested into helping with supporting testing of
<br>plugins further more, I'd be happy to discuss about it.
<br><br>Thanks,
<br><br>Antoine
<br><br>--
<br><a href="http://www.lunar-ocean.com/blog" target="_top" rel="nofollow">http://www.lunar-ocean.com/blog</a></div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-23208005New Committer: Daniel Spiewak2009-04-23T17:54:37Z2009-04-23T17:54:37ZAlex Boisvert-3Builders and shakers,
<br><br>I'm happy to announce that Daniel Spiewak has been elected as committer for
<br>Apache Buildr.
<br><br>Daniel has been an active contributor for some time now. He's fixed bugs,
<br>scratched his own itch, worked on various features (some of them already
<br>integrated, some of them still experimental but likely to eventually be
<br>integrated), he's been active on the mailing lists and written some good
<br>usage and advocacy posts on his blog. In short, he's been doing awesome
<br>work and we're ecstatic to have him join our project!
<br><br>Welcome Daniel!
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-22270402Re: Welcome to Rebase Hell!2009-02-28T22:40:20Z2009-02-28T22:40:20ZAssaf ArkinOn Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22270402&i=0" target="_top" rel="nofollow">djspiewak@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Those of you following development progress using Git are probably starting
<br>> to notice that the classical "Vic Master" is no longer the all-knowing
<br>> source of data. Actually, Assaf's GitHub fork has become the more
<br>> trustworthy one. This is because upon its exit from incubation, Buildr
<br>> gets
<br>> to move its SVN repository to a new URL. This is good for the project, but
<br>> bad for the Git forks since git-svn stores the URL information in its
<br>> commit
<br>> messages.
<br>>
<br>> The solution of course is to re-clone from SVN, which I assume exactly what
<br>> Assaf did. There result is a repository which contains all of the same SVN
<br>> commits as Vic's, but different messages and very different SHA1 revisions,
<br>> meaning that Git has a much harder time merging between the two. I
<br>> discovered this when I attempted to merge Assaf's latest changes with my
<br>> master (forked from Vic's). 57 conflicts later (all petty, little issues
<br>> unrelated to my additions), I finally had a working master with the latest
<br>> commits. Unfortunately, when I cloned Assaf's repository directly and
<br>> attempted to merge back some of my changes, it became very apparent that I
<br>> would need to fix the issue in a more scientific manner.
<br>>
<br>> Long story short, the solution is to rebase all of your branches onto
<br>> Assaf's master. I did this by finding the exact commit where I diverged
<br>> from vic (I had it tagged, actually) as well as the corresponding commit in
<br>> Assaf's master. These commits I tagged "branch-point" and
<br>> "new-branch-point", respectively. Then for each branch, I did something
<br>> like the following:
<br>>
<br>> git checkout scala-joint-compilation
<br>> git rebase new-branch-point
<br>>
<br>> Once this was done, I went back to my master and performed a similar
<br>> procedure:
<br>>
<br>> git checkout master
<br>> git rebase -s ours new-branch-point
<br>>
<br>> This effectively wiped out all of my changes in that branch (it's possible
<br>> that some commits may remain if you try it, but none did in my case). Once
<br>> this was done, I went and picked through my origin/master log to see what I
<br>> was missing. This meant re-merging all of my branches:
<br>>
<br>> git merge scala-joint-compilation
<br>> git merge clojure
<br>> ...
<br>>
<br>> Also, I had to cherry-pick a few commits that I had done on master (like
<br>> four or five):
<br>>
<br>> git cherry-pick all-your-ant-base
<br>> ...
<br>>
<br>> Once this was done, I pushed the result back to GitHub:
<br>>
<br>> git push -f origin
<br>>
<br>> The one caveat to this approach is I had all of my changes on numerous
<br>> separate branches (for patching reasons). All of these branches were
<br>> branched off of the same point on vic/master. Since there hadn't been any
<br>> merging *between* the branches (only onto master), it was fairly easy to
<br>> just rebase these branches onto the new trunk (I only had three conflicts
<br>> in
<br>> the whole process, all easily resolved). Just judging by GitHub, not many
<br>> people are managing their repositories in this fashion. However, this does
<br>> mean that you could be able to just rebase without the "-s ours" on your
<br>> master and come to the same result.
<br>>
<br>> The point is that you will need to perform some conniptions of this sort in
<br>> order to fix your repositories, otherwise your changes will remain
<br>> incompatible with the Buildr mainline trunk: you won't be able to (easily)
<br>> merge assaf/master, and he won't be able to (easily) pull from you.
<br>>
<br>> Incidentally, if anyone has a *better* way of doing this (particularly one
<br>> where the entire master history doesn't get wiped out), I'm all ears! I do
<br>> still have the unmerged repository sitting in Time Machine, so I'm
<br>> perfectly
<br>> willing to roll-forward a copy and try again if the result turns out to be
<br>> more correct.
</div><br><br>Thanks.
<br><br><br>AFAIK it's not possible to git svn clone directly from svn.apache.org due to
<br>some weird restriction they placed on the SVN server, it will just keep
<br>git-svn hanging forever. Somehow that doesn't affect incubator projects, or
<br>svn.eu.apache.org, although my starting point was Jukka's unofficial but
<br>somewhat official git mirror[1].
<br><br><br>When you git log, check the git-svn-id:
<br><br>commit a3ab30a66a092bf730950bd95a1394253ebd2f39
<br><br>Author: Assaf Arkin <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22270402&i=1" target="_top" rel="nofollow">assaf@...</a>>
<br><br>Date: Fri Feb 27 22:24:50 2009 +0000
<br><br><br>> Fixed RDoc 2.3/2.4 conflict on rake setup.
<br><br><br><br> git-svn-id:
<br><a href="https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68" target="_top" rel="nofollow">https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68</a><br><br><br>If two repositories use a different URL -- look for http vs https,
<br>svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr --
<br>Git considers them distinct trees (branches). Any time you merge, Git will
<br>have to merge the entire history of these two branches, leading to a lot of
<br>conflicts.
<br><br>So if you have branches with changes, follow Daniel's instructions. If you
<br>don't, you can still use the -s ours strategy to "switch" from one branch to
<br>another.
<br><br>Until Apache comes with a better solution, I'm going to keep my
<br>repository synchronized against <a href="https://svn.eu.apache.org/repos/asf/buildr" target="_top" rel="nofollow">https://svn.eu.apache.org/repos/asf/buildr</a>.
<br>I suggest you all do the same, that way we have the same history and can
<br>easily merge with each other.
<br><br>Assaf
<br><br>[1] <a href="http://jukka.zitting.name/git/" target="_top" rel="nofollow">http://jukka.zitting.name/git/</a><br><br><br><br>>
<br>>
<br>> Daniel
<br>>
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-22270020Re: Welcome to Rebase Hell!2009-02-28T21:09:56Z2009-02-28T21:09:56ZDaniel Spiewak> PS: I merged your "separate-scala-specs" branch so no need to sweat
<br>> through
<br>> that one.
<br><br><br>Cool! Did you get some of the more recent changes (documentation and RSpec
<br>specs)? I think I may have also changed some behavior somewhere to be more
<br>in-line with how Buildr's other test frameworks behave (probably failure).
<br><br>Daniel
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-22270011Re: Welcome to Rebase Hell!2009-02-28T21:05:48Z2009-02-28T21:05:48ZAlex Boisvert-3I'll simply quote Assaf from a few weeks ago:
<br><br>"Git-svn is the worse of Git and the worse of SVN"
<br><br>I have very low expectations that we'll find a suitable solution until we
<br>officially migrate to Git at Apache. Personally, I'm through playing merge
<br>roulette with git-svn...
<br><br>alex
<br><br>PS: I merged your "separate-scala-specs" branch so no need to sweat through
<br>that one.
<br><br><br>On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22270011&i=0" target="_top" rel="nofollow">djspiewak@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Those of you following development progress using Git are probably starting
<br>> to notice that the classical "Vic Master" is no longer the all-knowing
<br>> source of data. Actually, Assaf's GitHub fork has become the more
<br>> trustworthy one. This is because upon its exit from incubation, Buildr
<br>> gets
<br>> to move its SVN repository to a new URL. This is good for the project, but
<br>> bad for the Git forks since git-svn stores the URL information in its
<br>> commit
<br>> messages.
<br>>
<br>> The solution of course is to re-clone from SVN, which I assume exactly what
<br>> Assaf did. There result is a repository which contains all of the same SVN
<br>> commits as Vic's, but different messages and very different SHA1 revisions,
<br>> meaning that Git has a much harder time merging between the two. I
<br>> discovered this when I attempted to merge Assaf's latest changes with my
<br>> master (forked from Vic's). 57 conflicts later (all petty, little issues
<br>> unrelated to my additions), I finally had a working master with the latest
<br>> commits. Unfortunately, when I cloned Assaf's repository directly and
<br>> attempted to merge back some of my changes, it became very apparent that I
<br>> would need to fix the issue in a more scientific manner.
<br>>
<br>> Long story short, the solution is to rebase all of your branches onto
<br>> Assaf's master. I did this by finding the exact commit where I diverged
<br>> from vic (I had it tagged, actually) as well as the corresponding commit in
<br>> Assaf's master. These commits I tagged "branch-point" and
<br>> "new-branch-point", respectively. Then for each branch, I did something
<br>> like the following:
<br>>
<br>> git checkout scala-joint-compilation
<br>> git rebase new-branch-point
<br>>
<br>> Once this was done, I went back to my master and performed a similar
<br>> procedure:
<br>>
<br>> git checkout master
<br>> git rebase -s ours new-branch-point
<br>>
<br>> This effectively wiped out all of my changes in that branch (it's possible
<br>> that some commits may remain if you try it, but none did in my case). Once
<br>> this was done, I went and picked through my origin/master log to see what I
<br>> was missing. This meant re-merging all of my branches:
<br>>
<br>> git merge scala-joint-compilation
<br>> git merge clojure
<br>> ...
<br>>
<br>> Also, I had to cherry-pick a few commits that I had done on master (like
<br>> four or five):
<br>>
<br>> git cherry-pick all-your-ant-base
<br>> ...
<br>>
<br>> Once this was done, I pushed the result back to GitHub:
<br>>
<br>> git push -f origin
<br>>
<br>> The one caveat to this approach is I had all of my changes on numerous
<br>> separate branches (for patching reasons). All of these branches were
<br>> branched off of the same point on vic/master. Since there hadn't been any
<br>> merging *between* the branches (only onto master), it was fairly easy to
<br>> just rebase these branches onto the new trunk (I only had three conflicts
<br>> in
<br>> the whole process, all easily resolved). Just judging by GitHub, not many
<br>> people are managing their repositories in this fashion. However, this does
<br>> mean that you could be able to just rebase without the "-s ours" on your
<br>> master and come to the same result.
<br>>
<br>> The point is that you will need to perform some conniptions of this sort in
<br>> order to fix your repositories, otherwise your changes will remain
<br>> incompatible with the Buildr mainline trunk: you won't be able to (easily)
<br>> merge assaf/master, and he won't be able to (easily) pull from you.
<br>>
<br>> Incidentally, if anyone has a *better* way of doing this (particularly one
<br>> where the entire master history doesn't get wiped out), I'm all ears! I do
<br>> still have the unmerged repository sitting in Time Machine, so I'm
<br>> perfectly
<br>> willing to roll-forward a copy and try again if the result turns out to be
<br>> more correct.
<br>>
<br>> Daniel
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-22269965Welcome to Rebase Hell!2009-02-28T20:52:32Z2009-02-28T20:52:32ZDaniel SpiewakThose of you following development progress using Git are probably starting
<br>to notice that the classical "Vic Master" is no longer the all-knowing
<br>source of data. Actually, Assaf's GitHub fork has become the more
<br>trustworthy one. This is because upon its exit from incubation, Buildr gets
<br>to move its SVN repository to a new URL. This is good for the project, but
<br>bad for the Git forks since git-svn stores the URL information in its commit
<br>messages.
<br><br>The solution of course is to re-clone from SVN, which I assume exactly what
<br>Assaf did. There result is a repository which contains all of the same SVN
<br>commits as Vic's, but different messages and very different SHA1 revisions,
<br>meaning that Git has a much harder time merging between the two. I
<br>discovered this when I attempted to merge Assaf's latest changes with my
<br>master (forked from Vic's). 57 conflicts later (all petty, little issues
<br>unrelated to my additions), I finally had a working master with the latest
<br>commits. Unfortunately, when I cloned Assaf's repository directly and
<br>attempted to merge back some of my changes, it became very apparent that I
<br>would need to fix the issue in a more scientific manner.
<br><br>Long story short, the solution is to rebase all of your branches onto
<br>Assaf's master. I did this by finding the exact commit where I diverged
<br>from vic (I had it tagged, actually) as well as the corresponding commit in
<br>Assaf's master. These commits I tagged "branch-point" and
<br>"new-branch-point", respectively. Then for each branch, I did something
<br>like the following:
<br><br>git checkout scala-joint-compilation
<br>git rebase new-branch-point
<br><br>Once this was done, I went back to my master and performed a similar
<br>procedure:
<br><br>git checkout master
<br>git rebase -s ours new-branch-point
<br><br>This effectively wiped out all of my changes in that branch (it's possible
<br>that some commits may remain if you try it, but none did in my case). Once
<br>this was done, I went and picked through my origin/master log to see what I
<br>was missing. This meant re-merging all of my branches:
<br><br>git merge scala-joint-compilation
<br>git merge clojure
<br>...
<br><br>Also, I had to cherry-pick a few commits that I had done on master (like
<br>four or five):
<br><br>git cherry-pick all-your-ant-base
<br>...
<br><br>Once this was done, I pushed the result back to GitHub:
<br><br>git push -f origin
<br><br>The one caveat to this approach is I had all of my changes on numerous
<br>separate branches (for patching reasons). All of these branches were
<br>branched off of the same point on vic/master. Since there hadn't been any
<br>merging *between* the branches (only onto master), it was fairly easy to
<br>just rebase these branches onto the new trunk (I only had three conflicts in
<br>the whole process, all easily resolved). Just judging by GitHub, not many
<br>people are managing their repositories in this fashion. However, this does
<br>mean that you could be able to just rebase without the "-s ours" on your
<br>master and come to the same result.
<br><br>The point is that you will need to perform some conniptions of this sort in
<br>order to fix your repositories, otherwise your changes will remain
<br>incompatible with the Buildr mainline trunk: you won't be able to (easily)
<br>merge assaf/master, and he won't be able to (easily) pull from you.
<br><br>Incidentally, if anyone has a *better* way of doing this (particularly one
<br>where the entire master history doesn't get wiped out), I'm all ears! I do
<br>still have the unmerged repository sitting in Time Machine, so I'm perfectly
<br>willing to roll-forward a copy and try again if the result turns out to be
<br>more correct.
<br><br>Daniel
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-22240270A little too terse...2009-02-26T22:29:42Z2009-02-26T22:29:42ZAlex Boisvert-3This recent change,
<br><br>Running svn diff -r735809:744045 lib/buildr/core/application.rb
<br>r744045 | assaf | 2009-02-13 01:13:42 -0800 (Fri, 13 Feb 2009) | 3 lines
<br><br>Setting RakeFileUtils.verbose_flag to false prevents the annoying messages
<br>in every FileUtils method and sh call.
<br>Failure in test framework is now reported and the test allowed to fail
<br>properly, rather than miserably.
<br>Fixed failing tests in transport_spec.rb.
<br>Index: lib/buildr/core/application.rb
<br>===================================================================
<br>--- lib/buildr/core/application.rb (revision 735809)
<br>+++ lib/buildr/core/application.rb (revision 744045)
<br>@@ -263,6 +263,7 @@
<br><br> standard_buildr_options.each { |args| opts.on(*args) }
<br> parsed_argv = opts.parse(ARGV)
<br>+ RakeFileUtils.verbose_flag = options.trace
<br> parsed_argv
<br> end
<br><br>... has shut up much more than FileUtils operations on my system; I don't
<br>see messages such as:
<br><br>Building ode-axis215
<br>Compiling ode-axis215:utils into /home/boisvert/git/pxe/utils/target/classes
<br>Compiling ode-axis215:utils:test into
<br>/home/boisvert/git/pxe/utils/target/test/classes
<br>...
<br><br>anymore and I still see messages such as:
<br><br>rm -rf
<br>/home/boisvert/git/pxe/axis2/target
<br><br>rm -rf
<br>/home/boisvert/git/pxe/axis2/reports
<br><br>rm -rf
<br>/home/boisvert/git/pxe/bpel-api/target
<br><br>rm -rf
<br>/home/boisvert/git/pxe/bpel-api/reports
<br><br>rm -rf
<br>/home/boisvert/git/pxe/utils/target
<br><br>rm -rf /home/boisvert/git/pxe/utils/reports
<br><br>during cleaning.
<br><br>Is is just my system, or is there a better way?
<br><br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-22084096The Eclipse IP process ...2009-02-18T09:39:57Z2009-02-18T09:39:57ZAssaf Arkin... looks very similar to the Apache IP process(*), at least judging from
<br>this cartoon:
<br><br><a href="http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php" target="_top" rel="nofollow">http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php</a><br><br><br><br>(*) True, Buildr uses JIRA and not Bugzilla, we don't involve legal in every
<br>single release, we're trying to offload patches to Git, but by and large I
<br>think we achieve the same annoy factor as Eclipse
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-22002759February Board Report2009-02-13T10:55:44Z2009-02-13T10:55:44ZAlex Boisvert-3Hi,
<br><br>I wrote a draft of our February Board Report which is due by Sunday:
<br><a href="http://cwiki.apache.org/confluence/display/BUILDR/February+2009+Board+Report" target="_top" rel="nofollow">http://cwiki.apache.org/confluence/display/BUILDR/February+2009+Board+Report</a><br><br>Please comment or edit by tomorrow (Saturday) if you think I've missed
<br>anything.
<br><br>thanks,
<br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-21927531Fwd: BUILDR-2462009-02-09T20:26:01Z2009-02-09T20:26:01ZChristopher Gardner-2---------- Forwarded message ----------
<br>From: Christopher Gardner <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21927531&i=0" target="_top" rel="nofollow">chris.r.gardner@...</a>>
<br>Date: Mon, Feb 9, 2009 at 10:47 PM
<br>Subject: BUILDR-246
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21927531&i=1" target="_top" rel="nofollow">buildr-dev@...</a>
<br><br><br>Has anyone happened to look at the potential bug I posted?
<br><br><a href="https://issues.apache.org/jira/browse/BUILDR-246" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/BUILDR-246</a><br><br>In summary, the symptom is this:
<br><br>Invalid argument
<br>c:/ruby/1.8.7/lib/ruby/gems/1.8/gems/buildr-1.3.3/lib/buildr/java/tests.rb:62:in
<br>`new'
<br><br>when my tests are run. There are no problems (apparently) in
<br>compiling the source or JUnit tests. I'm using a custom directory
<br>structure for an existing project. I haven't tried to alter the
<br>existing structure to buildr's preferred determine if that is a
<br>contributing factor.
<br><br>Any thoughts?
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21927287BUILDR-2462009-02-09T19:47:54Z2009-02-09T19:47:54ZChristopher Gardner-2Has anyone happened to look at the potential bug I posted?
<br><br><a href="https://issues.apache.org/jira/browse/BUILDR-246" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/BUILDR-246</a><br><br>In summary, the symptom is this:
<br><br>Invalid argument
<br>c:/ruby/1.8.7/lib/ruby/gems/1.8/gems/buildr-1.3.3/lib/buildr/java/tests.rb:62:in
<br>`new'
<br><br>when my tests are run. There are no problems (apparently) in
<br>compiling the source or JUnit tests. I'm using a custom directory
<br>structure for an existing project. I haven't tried to alter the
<br>existing structure to buildr's preferred determine if that is a
<br>contributing factor.
<br><br>Any thoughts?
<br><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-21908005Re: Keeping executable bits on files (Buildr::Filter)2009-02-08T23:16:11Z2009-02-08T23:16:11ZAssaf ArkinOn Thu, Jan 29, 2009 at 12:36 PM, Alex Boisvert <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21908005&i=0" target="_top" rel="nofollow">boisvert@...</a>>wrote:
<br><div class='shrinkable-quote'><br>> Hi Henrik,
<br>>
<br>> Late reply but I guess better than no reply at all!
<br>>
<br>> On Tue, Jan 27, 2009 at 1:00 AM, Henrik Thostrup Jensen
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21908005&i=1" target="_top" rel="nofollow">thostrup@...</a>>wrote:
<br>>
<br>> > When copying files using Buildr:Filter, any executable bit set on
<br>> > files disappear.
<br>> > This is somewhat annoying :-). Is there a way to fix this?
<br>>
<br>>
<br>> Yes, but it sounds like we'll need a volunteer to write the fix and test
<br>> it. Feel free to open a Jira and give it your best shot if you have the
<br>> guts for it.
</div><br><br>Here's the issue:
<br><a href="https://issues.apache.org/jira/browse/BUILDR-144" target="_top" rel="nofollow">https://issues.apache.org/jira/browse/BUILDR-144</a><br><br>Assaf
<br><br><br><div class='shrinkable-quote'><br>>
<br>>
<br>> Also, is there an easy way to roll up several sub-projects into a
<br>> > single directory (for release or deployment)
<br>> > Currently I'm doing this filter, but there might be an easier way.
<br>>
<br>>
<br>> I'm not 100% clear about what you mean. Typically the form of packaging
<br>> you use (.war, .ear, ...) addresses this.
<br>>
<br>>
<br>>
<br>> > And two unrelated questions:
<br>> >
<br>> > 1.3.4 gets a bit verbose to stdout, even with --silent (e.g., clean
<br>> > emits alot of rm -fr command)
<br>> > Is there a way to make it as silent as 1.3.3?
<br>>
<br>>
<br>> Do you want to send in a patch? :)
<br>>
<br>>
<br>> > 1.3.4 didn't really speed up things. Maybe the actual task execution,
<br>> > but there is still a ~10 second startup delay. jirb takes around 2
<br>> > seconds to start. Is this common, or is JRuby misconfigured somehow?
<br>>
<br>>
<br>> I have an 5-8 second delay on my system. I think it's within the expected
<br>> norms without knowing more about your system configuration.
<br>>
<br>> alex
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21880928Resources & post-processing project definitions2009-02-06T13:11:03Z2009-02-06T13:11:03ZRhett SutphinHi,
<br><br>Synopsis: I'm having a problem with a buildfile where, if I define
<br>the resource paths outside of the initial project definition block,
<br>the resource target directories are not included on the classpath when
<br>running tests. The resources are copied to target (during the compile
<br>and test:compile tasks) and packaged correctly (if I do package
<br>test=no), but they are not visible to the tests.
<br><br>Details: I am converting an existing project to use buildr. It
<br>stores its resources alongside the code, so in each of the subprojects
<br>I have lines like these:
<br><br> resources.from(_("src/main/java")).exclude("**/*.java")
<br> test.resources.from(_("src/test/java")).exclude("**/*.java")
<br><br>Hoping to DRY this up a bit, I replaced those repeated blocks with
<br>this code at the end of my buildfile:
<br><br>projects.each do |p|
<br> if File.exist?(p._("src/main/java"))
<br> # All resources come from source path
<br> p.resources.from(p._("src/main/java")).exclude("**/*.java")
<br> p.test.resources.from(p._("src/test/java")).exclude("**/*.java")
<br> end
<br>end
<br><br>This introduced the problem I described in the synopsis. Two questions:
<br><br>- Is this a bug I should report on the issue tracker? Or is it
<br>expected behavior?
<br><br>- Is there a better way to do what I'm trying to do?
<br><br>Thanks,
<br>Rhett
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21735329Re: Keeping executable bits on files (Buildr::Filter)2009-01-29T12:36:22Z2009-01-29T12:36:22ZAlex Boisvert-3Hi Henrik,
<br><br>Late reply but I guess better than no reply at all!
<br><br>On Tue, Jan 27, 2009 at 1:00 AM, Henrik Thostrup Jensen
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21735329&i=0" target="_top" rel="nofollow">thostrup@...</a>>wrote:
<br><br>> When copying files using Buildr:Filter, any executable bit set on
<br>> files disappear.
<br>> This is somewhat annoying :-). Is there a way to fix this?
<br><br><br>Yes, but it sounds like we'll need a volunteer to write the fix and test
<br>it. Feel free to open a Jira and give it your best shot if you have the
<br>guts for it.
<br><br>Also, is there an easy way to roll up several sub-projects into a
<br>> single directory (for release or deployment)
<br>> Currently I'm doing this filter, but there might be an easier way.
<br><br><br>I'm not 100% clear about what you mean. Typically the form of packaging
<br>you use (.war, .ear, ...) addresses this.
<br><br><br><br>> And two unrelated questions:
<br>>
<br>> 1.3.4 gets a bit verbose to stdout, even with --silent (e.g., clean
<br>> emits alot of rm -fr command)
<br>> Is there a way to make it as silent as 1.3.3?
<br><br><br>Do you want to send in a patch? :)
<br><br><br>> 1.3.4 didn't really speed up things. Maybe the actual task execution,
<br>> but there is still a ~10 second startup delay. jirb takes around 2
<br>> seconds to start. Is this common, or is JRuby misconfigured somehow?
<br><br><br>I have an 5-8 second delay on my system. I think it's within the expected
<br>norms without knowing more about your system configuration.
<br><br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21681839Keeping executable bits on files (Buildr::Filter)2009-01-27T01:00:36Z2009-01-27T01:00:36ZHenrik Thostrup Jensen[ This mail is a repost, but it didn't seem to make it. At least not
<br>to the archive ]
<br><br>Hi
<br><br>When copying files using Buildr:Filter, any executable bit set on
<br>files disappear.
<br>This is somewhat annoying :-). Is there a way to fix this?
<br><br>Also, is there an easy way to roll up several sub-projects into a
<br>single directory (for release or deployment)
<br>Currently I'm doing this filter, but there might be an easier way.
<br><br><br>And two unrelated questions:
<br><br>1.3.4 gets a bit verbose to stdout, even with --silent (e.g., clean
<br>emits alot of rm -fr command)
<br>Is there a way to make it as silent as 1.3.3?
<br><br>1.3.4 didn't really speed up things. Maybe the actual task execution,
<br>but there is still a ~10 second startup delay. jirb takes around 2
<br>seconds to start. Is this common, or is JRuby misconfigured somehow?
<br><br>Sorry for packing all the question into a single mail.
<br><br><br>--
<br> - Henrik
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21647192Re: junit test problem in 1.32009-01-24T16:38:47Z2009-01-24T16:38:47ZRafal RusinI had a similar problem. A solution is to use braces:
<br>test.using :java_args => ["-ea"]
<br><br>Regards,
<br>Rafal Rusin
<br><br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Assaf Arkin wrote:</div>
<div class="quote-message shrinkable-quote">On Sat, May 10, 2008 at 8:28 PM, Dustin Sallings <dustin@spy.net> wrote:
<br><br>>
<br>> I just upgraded to buildr 1.3 and figure out how to get my junit
<br>> tests running with assertions enabled. The following does nothing:
<br>>
<br>> test.using :java_args => "-ea"
<br>>
<br>> Any ideas?
<br><br><br>Add this in svn/git, can you test it out?
<br><br>Assaf
<br><br><br>>
<br>>
<br>> --
<br>> Dustin Sallings
<br>>
<br>>
<br>>
<br>>
<br><br><br>--
<br>CTO, Intalio
<br><a href="http://www.intalio.com" target="_top" rel="nofollow">http://www.intalio.com</a></div>
</div></blockquote>
<p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21622929Keeping executable bits on files (Buildr::Filter)2009-01-23T03:35:42Z2009-01-23T03:35:42ZHenrik Thostrup JensenHi
<br><br>When copying files using Buildr:Filter, any executable bit set on
<br>files disappear.
<br>This is somewhat annoying :-). Is there a way to fix this?
<br><br>Also, is there an easy way to roll up several sub-projects into a
<br>single directory (for release or deployment)
<br>Currently I'm doing this filter, but there might be an easier way.
<br><br><br>And two unrelated questions:
<br><br>1.3.4 gets a bit verbose to stdout, even with --silent (e.g., clean
<br>emits alot of rm -fr command)
<br>Is there a way to make it as silent as 1.3.3?
<br><br>1.3.4 didn't really speed up things. Maybe the actual task execution,
<br>but there is still a ~10 second startup delay. jirb takes around 2
<br>seconds to start. Is this common, or is JRuby misconfigured somehow?
<br><br>Sorry for packing all the question into a single mail.
<br><br>--
<br> - Henrik
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21577239Re: checkstyle integration with buildr2009-01-20T21:07:23Z2009-01-20T21:07:23ZHaritha Reddy<br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Haritha Reddy-2 wrote:</div>
<div class="quote-message shrinkable-quote">I am trying to create an addon for generation of checkstyle reports into
<br>buildr. The attached checkstyle.rb contains checkstyle:html ( xsl_file=?
<br>config_file=?) and checkstyle:xml (config_file=?)tasks to create checkstyle
<br>reports.
<br><br>
<br><br>If the command line arguments are not provided for xsl_file and config_file
<br>, it expects that checkstyle_checks.xml and checkstyle.xsl files are present
<br>in the folder where buildfile is located.
<br><br>
<br><br>Is there a better way to handle the default case?
<br><br>
<br><br>Thanks
<br><br>Haritha
<br><br>
<br></div>
</div></blockquote>
<a href="http://old.nabble.com/file/p21577239/checkstyle.rb" target="_top">checkstyle.rb</a><p>From forum: <a href="http://old.nabble.com/Buildr---Dev-f28731.html" embed="fixTarget[28731]" target="_top" >Buildr - Dev</a></p>tag:old.nabble.com,2006:post-21484646Re: Postponing test compile to after all modules have compiled2009-01-15T11:04:22Z2009-01-15T11:04:22ZAssaf ArkinOn Thu, Jan 15, 2009 at 9:49 AM, Henrik Thostrup Jensen
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21484646&i=0" target="_top" rel="nofollow">thostrup@...</a>> wrote:
<div class='shrinkable-quote'><br>> 2009/1/15 Assaf Arkin <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21484646&i=1" target="_top" rel="nofollow">arkin@...</a>>:
<br>>> On Thu, Jan 15, 2009 at 1:38 AM, Henrik Thostrup Jensen
<br>>>>
<br>>>> Any ideas, before I bow my head, and go back to maven :-(.
<br>>>
<br>>> Buildr for JRuby.
<br>>>
<br>>> I had similar issue under Ubuntu, Ruby and JDK 1.6. If I ran a task
<br>>> that took a while, say a minute, Buildr would seg fault at some point,
<br>>> not always the same point. No such problem with Ruby/1.5 or JRuby/1.6,
<br>>> so I would recommend switching to JRuby.
<br>>
<br>> Switching to JRuby fixed the segfaults, and I now have a working build.
<br>>
<br>> Is a bit sluggish tough (10 seconds for clean). Is there a way to improve this?
</div><br>1.3.4 will cut down the start time, you can give it a try:
<br><a href="http://incubator.apache.org/buildr/contributing.html#living_on_the_edge" target="_top" rel="nofollow">http://incubator.apache.org/buildr/contributing.html#living_on_the_edge</a><br><br>Assaf
<br><br>>
<br>> I will find a way to work around the semi-circular dependency for now.
<br>>
<br>>
<br>> --
<br>> - Henrik
<br>>
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21483106Re: Postponing test compile to after all modules have compiled2009-01-15T09:49:14Z2009-01-15T09:49:14ZHenrik Thostrup Jensen2009/1/15 Assaf Arkin <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21483106&i=0" target="_top" rel="nofollow">arkin@...</a>>:
<div class='shrinkable-quote'><br>> On Thu, Jan 15, 2009 at 1:38 AM, Henrik Thostrup Jensen
<br>>>
<br>>> Any ideas, before I bow my head, and go back to maven :-(.
<br>>
<br>> Buildr for JRuby.
<br>>
<br>> I had similar issue under Ubuntu, Ruby and JDK 1.6. If I ran a task
<br>> that took a while, say a minute, Buildr would seg fault at some point,
<br>> not always the same point. No such problem with Ruby/1.5 or JRuby/1.6,
<br>> so I would recommend switching to JRuby.
</div><br>Switching to JRuby fixed the segfaults, and I now have a working build.
<br><br>Is a bit sluggish tough (10 seconds for clean). Is there a way to improve this?
<br><br>I will find a way to work around the semi-circular dependency for now.
<br><br><br>--
<br> - Henrik
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21481168Re: Postponing test compile to after all modules have compiled2009-01-15T08:25:46Z2009-01-15T08:25:46ZAssaf ArkinOn Thu, Jan 15, 2009 at 1:38 AM, Henrik Thostrup Jensen
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21481168&i=0" target="_top" rel="nofollow">thostrup@...</a>> wrote:
<div class='shrinkable-quote'><br>> 2009/1/15 Ittay Dror <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21481168&i=1" target="_top" rel="nofollow">ittayd@...</a>>:
<br>>>
<br>>> Alex Boisvert wrote:
<br>>>>
<br>>>> The only segfaults I've seen on Ubuntu were cases using JDK 1.6 with RJB.
<br>>>> You can use either JDK 1.5 or switch to JRuby if you want to use JDK 1.6.
<br>>>
<br>>> I have run into many segfaults. The reason is usually a deep recursion which
<br>>> exhausts the execution stack (a ruby stack of 20 methods is something like
<br>>> 400 c functions stack). Since Rake uses recursion to invoke prerequisites of
<br>>> tasks and since Buildr uses a lot of task dependencies (e.g. compile.with
<br>>> project('B')), this happens when the project tree gets large. As far as I
<br>>> remember this happens on *nix systems, not Windows.
<br>>>
<br>>> The way I debug this is by using trace to find where approximately the crash
<br>>> happens and then turning on method tracing in ruby.
<br>>>
<br>>> If running on *nix, try increasing the stack limit ('ulimit -s unlimited')
<br>>
<br>> I tried this and compared buildr --trace with regular ulimit, it
<br>> doesn't get any further :-/.
<br>> The dependencies in the project are quite complex.
<br>>
<br>> I am also using JDK 1.6, and tried to downgrade to 1.5. However many
<br>> (most) of the libraries I need to use are compiled with 1.6, making a
<br>> downgrade very inconvenient.
<br>>
<br>> The segfaults does not appear to come a particular place though:
<br>>
<br>> ** Invoke sgas:iterator:build (first_time)
<br>> ** Invoke sgas:common:test:compile (first_time, not_needed)
<br>> zsh: segmentation fault buildr --trace
<br>>
<br>> ** Invoke /home/htj/src/sgas/sgas-git-buildr/buildfile (not_needed)
<br>> ** Invoke /home/htj/src/sgas/sgas-git-buildr/iterator/target/main/classes
<br>> (first_time)
<br>> zsh: segmentation fault buildr --trace
<br>>
<br>> Any ideas, before I bow my head, and go back to maven :-(.
</div><br>Buildr for JRuby.
<br><br>I had similar issue under Ubuntu, Ruby and JDK 1.6. If I ran a task
<br>that took a while, say a minute, Buildr would seg fault at some point,
<br>not always the same point. No such problem with Ruby/1.5 or JRuby/1.6,
<br>so I would recommend switching to JRuby.
<br><br>Assaf
<br><br>>
<br>> --
<br>> - Henrik
<br>>
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21479507Re: Postponing test compile to after all modules have compiled2009-01-15T07:04:27Z2009-01-15T07:04:27ZHenrik Thostrup Jensen2009/1/15 Daniel Spiewak <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21479507&i=0" target="_top" rel="nofollow">djspiewak@...</a>>:
<br>> Could this be an incompatibility with Buildr and ZSH? It looks to me like
<br>> that's where the problem is considering the fact that Buildr moves on after
<br>> the segfault.
<br>>
<br>> I use Buildr with Bash.
<br><br>Those are actually two different segfaults (in order to show that the
<br>segfault doesn't occur in any specific phase).
<br><br>I also tried with bash, but same result.
<br><br>I did a quick core dump and back trace with gdb, but got the following
<br>(rather useless) result:
<br><br>(gdb) bt
<br>#0 0xb7eaccb7 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#1 0xb7eacd5a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#2 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#3 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#4 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#5 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#6 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#7 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#8 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#9 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#10 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#11 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#12 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#13 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#14 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#15 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#16 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#17 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#18 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#19 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#20 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#21 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#22 0xb7ead141 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#23 0xb7eae0a2 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#24 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#25 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#26 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#27 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#28 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#29 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#30 0xb7eae294 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#31 0xb7eb2781 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#32 0xb7eb2a1a in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#33 0xb7ead021 in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#34 0xb7eb0dbc in ?? () from /usr/lib/libruby1.8.so.1.8
<br>#35 0xb7ebc847 in rb_yield () from /usr/lib/libruby1.8.so.1.8
<br>#36 0xb7e8cf91 in rb_ary_each () from /usr/lib/libruby1.8.so.1.8
<br>[---- much more ----]
<br><br>Which doesn't reveal much. The stack level was 564 levels deep though.
<br><br>--
<br> - Henrik
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21479258Re: Postponing test compile to after all modules have compiled2009-01-15T06:51:16Z2009-01-15T06:51:16ZDaniel SpiewakCould this be an incompatibility with Buildr and ZSH? It looks to me like
<br>that's where the problem is considering the fact that Buildr moves on after
<br>the segfault.
<br><br>I use Buildr with Bash.
<br><br>Daniel
<br><br>On Thu, Jan 15, 2009 at 3:38 AM, Henrik Thostrup Jensen
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21479258&i=0" target="_top" rel="nofollow">thostrup@...</a>>wrote:
<br><div class='shrinkable-quote'><br>> 2009/1/15 Ittay Dror <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21479258&i=1" target="_top" rel="nofollow">ittayd@...</a>>:
<br>> >
<br>> > Alex Boisvert wrote:
<br>> >>
<br>> >> The only segfaults I've seen on Ubuntu were cases using JDK 1.6 with
<br>> RJB.
<br>> >> You can use either JDK 1.5 or switch to JRuby if you want to use JDK
<br>> 1.6.
<br>> >
<br>> > I have run into many segfaults. The reason is usually a deep recursion
<br>> which
<br>> > exhausts the execution stack (a ruby stack of 20 methods is something
<br>> like
<br>> > 400 c functions stack). Since Rake uses recursion to invoke prerequisites
<br>> of
<br>> > tasks and since Buildr uses a lot of task dependencies (e.g. compile.with
<br>> > project('B')), this happens when the project tree gets large. As far as I
<br>> > remember this happens on *nix systems, not Windows.
<br>> >
<br>> > The way I debug this is by using trace to find where approximately the
<br>> crash
<br>> > happens and then turning on method tracing in ruby.
<br>> >
<br>> > If running on *nix, try increasing the stack limit ('ulimit -s
<br>> unlimited')
<br>>
<br>> I tried this and compared buildr --trace with regular ulimit, it
<br>> doesn't get any further :-/.
<br>> The dependencies in the project are quite complex.
<br>>
<br>> I am also using JDK 1.6, and tried to downgrade to 1.5. However many
<br>> (most) of the libraries I need to use are compiled with 1.6, making a
<br>> downgrade very inconvenient.
<br>>
<br>> The segfaults does not appear to come a particular place though:
<br>>
<br>> ** Invoke sgas:iterator:build (first_time)
<br>> ** Invoke sgas:common:test:compile (first_time, not_needed)
<br>> zsh: segmentation fault buildr --trace
<br>>
<br>> ** Invoke /home/htj/src/sgas/sgas-git-buildr/buildfile (not_needed)
<br>> ** Invoke /home/htj/src/sgas/sgas-git-buildr/iterator/target/main/classes
<br>> (first_time)
<br>> zsh: segmentation fault buildr --trace
<br>>
<br>> Any ideas, before I bow my head, and go back to maven :-(.
<br>>
<br>> --
<br>> - Henrik
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>tag:old.nabble.com,2006:post-21479234Re: Postponing test compile to after all modules have compiled2009-01-15T06:50:12Z2009-01-15T06:50:12ZAlex Boisvert-3On Wed, Jan 14, 2009 at 2:35 PM, Henrik Thostrup Jensen
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=21479234&i=0" target="_top" rel="nofollow">thostrup@...</a>>wrote:
<br><br>> Some of the tests in a module (say A) depends on a module (B), which
<br>> requires A to build. So I need to make buildr understand that it
<br>> should do something like:
<br>>
<br>> A.compile, B.compile (with A), A.test.compile (with B).
<br><br><br>This cannot be made to work with Buildr at the moment. You would need to
<br>introduce a new project (C) to break the circular dependency, or merge
<br>things in the same project (everything in A).
<br><br>(If you're insistent on the file layout with test files in A, then you could
<br>disable the tests in A and map C's test files to A's directory structure.
<br>It's somewhat of a hack but works...)
<br><br>alex
<br><p>From forum: <a href="http://old.nabble.com/Buildr---User-f28730.html" embed="fixTarget[28730]" target="_top" >Buildr - User</a></p>