Re: Run tasks

[Assaf Arkin]

On Thu, Jan 28, 2010 at 7:15 PM, Nicholas Andrews n...@jhu.edu wrote:

 Hi,

 I want to have several buildr run tasks.  My current run task looks like
 this:

 task :run = :compile do
Java.java cc.HelloWorld, arg1,
:classpath = [ compile.dependencies, compile.target ],
:java_args = [-server, -Xmx2048m]
 end

 I thought I could just do:

 task :run_with_blah to run with, say, cc.ByeByeWorld instead, but I
 get a don't know what to do with run_with_blah error when I try to
 run `buildr run_with_blah`.

 The other thing I want is to be able to pass parameters to whatever it
 is I'm running, instead of having to hard-code it in the build script.
  Can you access command line options from the buildfile script, or
 does buildr eat them when it interprets it?  E.g.,

 $ buildr run file1 file2


Here's the documentation for defining tasks that take arguments:
http://github.com/jimweirich/rake/blob/cb9fc5d19663108986c92f4608da489a0dfb9875/doc/release_notes/rake-0.8.3.rdoc

Since Buildr uses Rake's tasks and command line parser, it will work the
same way when you run the buildr command.

Assaf




 and use file1 and file2 as arguments to the class called in run.  This
 could work for different main classes as well, where I'd just pass the
 class name as an argument like

 $ buildr run HelloWorld arg1 arg2

 There may be a nicer way to accomplish what I'm doing here, for
 instance with a testing framework.  I'd welcome any suggestions along
 these lines too.

 Cheers,
 Nick

Re: Bundled Buildr + JRuby distribution

[Assaf Arkin]

On Thu, Dec 17, 2009 at 7:27 AM, Alex Boisvert alex.boisv...@gmail.comwrote:

 Hi Ittay,

 I'm unclear as to whether we'll be able to distribute it on the Apache
 site.   We'll need to review the license on all packaged software against
 Apache policies.


Official Apache releases are source code and have to be clear of any
licensing issues.

There's more flexibility with convenience binary downloads (that are not
official releases), as long as they don't cause any licensing violations and
people won't get them confused with official releases.

Assaf



 My intention is definitely to synchronize the release of the all-in-one
 JRuby distribution with the official Apache Buildr release and worse case,
 distribute it via separate channels and link to it from our site -- not
 unlike what we do with RubyForge/GemCutter.

 If you have suggestions, I'm all ears.

 alex

 On Thu, Dec 17, 2009 at 12:37 AM, Ittay Dror ittay.d...@gmail.com wrote:

  Any plans on making the distribution available in the site? Maybe using
  --fast to run jruby and jrubyc to precompile all ruby files?
 
  Thanks
  Ittay
 
 
  Alex Boisvert wrote:
 
  Hi,
 
  I've created an experimental distribution of Buildr 1.3.5 and JRuby
 1.4.0
  and made it available at:
  http://people.apache.org/~boisvert/buildr-1.3.5-jruby-1.4.0.zip
 http://people.apache.org/%7Eboisvert/buildr-1.3.5-jruby-1.4.0.zip
 
  The distro is 15M -- not too bad.  I've trimmed the packaged JRuby of
  everything I could that didn't affect functionality, such as
 documentation
  and Ruby 1.9 support.
 
  To use it, simply
1) unzip in a directory,
2) set your PATH to point to the bin directory, and
3) run buildr as usual.
 
  Looking for feedback on how it works as a quick way to get
 yourself/other
  people started.  If there's enough interest, it could become part of our
  supported distros.
 
  thanks,
  alex
 
 
 
 

Re: rjb-1.1.9 does not build on Windows with JDK in default location

[Assaf Arkin]

On Thu, Dec 17, 2009 at 10:29 AM, Will Rogers wjrog...@gmail.com wrote:

 On Thu, Dec 17, 2009 at 1:23 PM, Assaf Arkin as...@labnotes.org wrote:
   2. The version rjb-1.1.9 required by buildr-1.3.5 does not build when
 your
   JAVA_HOME has spaces in the path
 
  I'm not sure why you're getting the all-platforms gem with RJB 1.1.9
  dependency, but you shouldn't.   Could be one of the gems was in the
  switchover from Rubyforge to Gemcutter?

 The latest versions of the Ruby one click installer are compiled with
 mingw, not msvc6, and I believe that means they are not binary
 compatible with -mswin32 gems. Rubygems selects the basic
 all-platforms gems with this build of Ruby.


I think they're just using a different platform identifier, because their
suggestion is:

gem install --platform=mswin32
http://wiki.github.com/oneclick/rubyinstaller/gem-list

Could be targeted with a specific Buildr gem that's identical to -mswin32
but has the proper platform identifier to match one-click installer.

Assaf

Re: Is there a way to delay building a sub project?

[Assaf Arkin]

On Wed, Oct 28, 2009 at 1:19 PM, Andrew Moore rp.andrew.mo...@gmail.comwrote:



 Hi,

 I want to add a sub project to our buildr project that only runs if I
 specifically specify it, and not when I run the basic clean, build, package
 commands from the root. These are basically integration type tests that I
 want our continuous integration system to run, after it deploys,
 initializes
 and starts up our web application.

 I figure either I define the sub project dynamically in a task (which I
 haven't been able to get working) or I have some sort of way of testing
 what
 buildr command was used when the sub project's tasks are invoked and
 somehow
 enable or disable them to run based on that command (i.e., if the command
 invoking buildr contains the text: root-proj:integration-sub-project: or
 the directory the command ran from ends with /integration-sub-project).


You can use environment variables:

if ENV[CI]
  define 
  end
end

and then run buildr compile CI=true


You can use multiple parent projects (which can share the same base
directory):
http://github.com/apache/ode/blob/trunk/Buildfile

Assaf


 Any ideas how I can accomplish this?

 Thanks in advance for the help!

 Regards,

 Andrew



 --
 View this message in context:
 http://n2.nabble.com/Is-there-a-way-to-delay-building-a-sub-project-tp3907935p3907935.html
 Sent from the Apache Buildr - User mailing list archive at Nabble.com.

Re: helper for directories

[Assaf Arkin]

On Fri, Oct 23, 2009 at 1:02 AM, Peter Schröder p...@blau.de wrote:

 hi there,

 i am looking for the way that buildr is creating directories on
 demand. i would like to use some magic like if the directory is
 missing, just create it! so that i dont have to create the
 directories myself.


Rake has a nice way of handling this using dependencies:

  directory foo/bar

  file foo/bar/baz.h=foo/bar do
# create baz.h, directory exists ...
  end

Personally, I use mkdir_p, which will create parent directories as
necessary, and not complain if directory already exists:

  file foo/bar/baz.h do
mkdir_p foo/bar
# create baz.h, directory exists ...
  end

Assaf




 kind regards,
 peter

A brief introduction to Rake

[Assaf Arkin]

Blog post by John Barnette, short and to the point:
http://www.jbarnette.com/2009/08/27/on-rake.html

Assaf

Re: Running several jetty instances in different subprojects

[Assaf Arkin]

On Wed, Jul 22, 2009 at 6:48 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi Assaf,

 thanx a lot, now I got it - it's so easy :-)

 I also updated the wiki:
 http://cwiki.apache.org/confluence/display/BUILDR/How+to+run+jetty


Nice.

Assaf


 http://cwiki.apache.org/confluence/display/BUILDR/How+to+run+jetty

 Thanx  cheers,
 Martin



 On Wed, 2009-07-22 at 02:05 -0700, Assaf Arkin wrote:
  On Tue, Jul 21, 2009 at 1:46 PM, Martin Grotzke 
  martin.grot...@javakaffee.de wrote:
 
   On Tue, 2009-07-21 at 11:02 -0700, Assaf Arkin wrote:
On Tue, Jul 21, 2009 at 2:50 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:
   
 Hi Assaf,

 thanx for your response! Unfortunately, I don't see how/where to
 use
   the
 Jetty.new exactly.

 When I just Jetty.new(foo, http://localhost:8090;) then buildr
 complains about
  uninitialized constant Jetty
   
   
Try Buildr::Jetty.new( …
   Sorry, but I just don't get it. Where shall this go to? I still want to
   be able to run jetty in two subprojects. What I'm using in one
   subproject until now is this:
  
  task(jetty=[package(:war), jetty.use]) do |task|
jetty.deploy(http://localhost:8080;, task.prerequisites.first)
puts 'Press CTRL-C to stop Jetty'
trap 'SIGINT' do
  jetty.stop
end
Thread.stop
  end
  
   What is required so that I can use different instances of jetty in
   different subprojects?
  
 
  When you call the jetty method, you get a single instance of the Jetty
 class
  [1].  That's clearly not what you want, so don't call the jetty method --
  create the instance directly and use that instance instead of the one
  returned by the jetty method.  It's just an object and all you need is a
  variable to reference it.
 
 
  Assaf
 
  [1]
 
 http://github.com/apache/buildr/blob/a25989f6aaa79a25e9727237977cde248918286e/addon/buildr/jetty.rb#L244-246
 
 
  
  
   Thanx  cheers,
   Martin
  
  
  
   
To limit namespace pollution, everything is defined in the Buildr
   namespace.
 A lot of stuff is also conveniently accessible from the global
   namespace,
so global namespace is good place to look for thing, if not there,
 try
   the
Buildr namespace.
   
Assaf
   
   


 Can you provide a more complete example?

 Thanx  cheers,
 Martin


 On Mon, 2009-07-20 at 20:04 -0700, Assaf Arkin wrote:
  On Mon, Jul 20, 2009 at 8:57 AM, Martin Grotzke 
  martin.grot...@javakaffee.de wrote:
 
   Hi,
  
   our project contains several subprojects. Two of them I want to
 run
 with
   jetty, both instances shall be running at the same time.
  
   To change the port for one of the instances, I use
jetty.url = http://localhost:8090;
   in the context of one subproject, but this seems to change also
 the
   url
   for the jetty task defined in the different subproject.
  
   That's how I define the jetty tasks:
  
   define myproj do
  
define subprojA do
  ...
  task(jetty=[package(:war), jetty.use]) do |task|
jetty.deploy(http://localhost:8080;,
   task.prerequisites.first)
puts 'Press CTRL-C to stop Jetty'
trap 'SIGINT' do
  jetty.stop
end
Thread.stop
  end
  
end
  
define subprojB do
  
  jetty.url = http://localhost:8090;
  task(jetty=[package(:war), jetty.use]) do |task|
jetty.deploy(http://localhost:8090;,
   task.prerequisites.first)
puts 'Press CTRL-C to stop Jetty'
trap 'SIGINT' do
  jetty.stop
end
Thread.stop
  end
  
end
  
   end
  
   When I run the first jetty with
buildr myproj:subprojA
   it fails with
   ...
   Starting Jetty at http://localhost:8090
   1 [main] INFO org.mortbay.log - Logging to
   org.slf4j.impl.SimpleLogger(org.mortbay.log) via
 org.mortbay.log.Slf4jLog
   15 [main] INFO org.mortbay.log - jetty-6.1.3
   74 [main] INFO org.mortbay.log - Started SocketConnector @
 0.0.0.0:8090
   Jetty started
   Buildr aborted!
   Connection refused - connect(2)
  
  
   Is it somehow possible to run several jetty instances for
 different
   subprojects?
 
 
  Each time you call the jetty method it will return the same one
   instance
 of
  jetty.  The jetty task is run after the buildfile, at which point
 the
 last
  value you set to jetty.url is the current value, which happens to
 be
 8090.
 
  If you want multiple instances, Jetty.new(name, url) and give
 each
   one a
  different URL.  Name is used to namespace the setup/teardown/use
   task, so
  you can use the same name for all instances, or pick different
 one.
 
  Assaf

Re: Running several jetty instances in different subprojects

[Assaf Arkin]

On Tue, Jul 21, 2009 at 2:50 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi Assaf,

 thanx for your response! Unfortunately, I don't see how/where to use the
 Jetty.new exactly.

 When I just Jetty.new(foo, http://localhost:8090;) then buildr
 complains about
  uninitialized constant Jetty


Try Buildr::Jetty.new( …

To limit namespace pollution, everything is defined in the Buildr namespace.
 A lot of stuff is also conveniently accessible from the global namespace,
so global namespace is good place to look for thing, if not there, try the
Buildr namespace.

Assaf




 Can you provide a more complete example?

 Thanx  cheers,
 Martin


 On Mon, 2009-07-20 at 20:04 -0700, Assaf Arkin wrote:
  On Mon, Jul 20, 2009 at 8:57 AM, Martin Grotzke 
  martin.grot...@javakaffee.de wrote:
 
   Hi,
  
   our project contains several subprojects. Two of them I want to run
 with
   jetty, both instances shall be running at the same time.
  
   To change the port for one of the instances, I use
jetty.url = http://localhost:8090;
   in the context of one subproject, but this seems to change also the url
   for the jetty task defined in the different subproject.
  
   That's how I define the jetty tasks:
  
   define myproj do
  
define subprojA do
  ...
  task(jetty=[package(:war), jetty.use]) do |task|
jetty.deploy(http://localhost:8080;, task.prerequisites.first)
puts 'Press CTRL-C to stop Jetty'
trap 'SIGINT' do
  jetty.stop
end
Thread.stop
  end
  
end
  
define subprojB do
  
  jetty.url = http://localhost:8090;
  task(jetty=[package(:war), jetty.use]) do |task|
jetty.deploy(http://localhost:8090;, task.prerequisites.first)
puts 'Press CTRL-C to stop Jetty'
trap 'SIGINT' do
  jetty.stop
end
Thread.stop
  end
  
end
  
   end
  
   When I run the first jetty with
buildr myproj:subprojA
   it fails with
   ...
   Starting Jetty at http://localhost:8090
   1 [main] INFO org.mortbay.log - Logging to
   org.slf4j.impl.SimpleLogger(org.mortbay.log) via
 org.mortbay.log.Slf4jLog
   15 [main] INFO org.mortbay.log - jetty-6.1.3
   74 [main] INFO org.mortbay.log - Started SocketConnector @
 0.0.0.0:8090
   Jetty started
   Buildr aborted!
   Connection refused - connect(2)
  
  
   Is it somehow possible to run several jetty instances for different
   subprojects?
 
 
  Each time you call the jetty method it will return the same one instance
 of
  jetty.  The jetty task is run after the buildfile, at which point the
 last
  value you set to jetty.url is the current value, which happens to be
 8090.
 
  If you want multiple instances, Jetty.new(name, url) and give each one a
  different URL.  Name is used to namespace the setup/teardown/use task, so
  you can use the same name for all instances, or pick different one.
 
  Assaf
 
  
  
  
   Thanx  cheers,
   Martin
  
  

Re: Running several jetty instances in different subprojects

[Assaf Arkin]

On Mon, Jul 20, 2009 at 8:57 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi,

 our project contains several subprojects. Two of them I want to run with
 jetty, both instances shall be running at the same time.

 To change the port for one of the instances, I use
  jetty.url = http://localhost:8090;
 in the context of one subproject, but this seems to change also the url
 for the jetty task defined in the different subproject.

 That's how I define the jetty tasks:

 define myproj do

  define subprojA do
...
task(jetty=[package(:war), jetty.use]) do |task|
  jetty.deploy(http://localhost:8080;, task.prerequisites.first)
  puts 'Press CTRL-C to stop Jetty'
  trap 'SIGINT' do
jetty.stop
  end
  Thread.stop
end

  end

  define subprojB do

jetty.url = http://localhost:8090;
task(jetty=[package(:war), jetty.use]) do |task|
  jetty.deploy(http://localhost:8090;, task.prerequisites.first)
  puts 'Press CTRL-C to stop Jetty'
  trap 'SIGINT' do
jetty.stop
  end
  Thread.stop
end

  end

 end

 When I run the first jetty with
  buildr myproj:subprojA
 it fails with
 ...
 Starting Jetty at http://localhost:8090
 1 [main] INFO org.mortbay.log - Logging to
 org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
 15 [main] INFO org.mortbay.log - jetty-6.1.3
 74 [main] INFO org.mortbay.log - Started SocketConnector @ 0.0.0.0:8090
 Jetty started
 Buildr aborted!
 Connection refused - connect(2)


 Is it somehow possible to run several jetty instances for different
 subprojects?


Each time you call the jetty method it will return the same one instance of
jetty.  The jetty task is run after the buildfile, at which point the last
value you set to jetty.url is the current value, which happens to be 8090.

If you want multiple instances, Jetty.new(name, url) and give each one a
different URL.  Name is used to namespace the setup/teardown/use task, so
you can use the same name for all instances, or pick different one.

Assaf




 Thanx  cheers,
 Martin

Re: How to run task in background

[Assaf Arkin]

On Fri, Jul 10, 2009 at 3:17 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi,

 I have another one :)

 I want to start a mailserver with test.setup so that it's available for
 tests.

 I created a task that starts a simple java mail server which blocks
 until it's interrupted. Now I wonder how it's possible to run this in
 the background during the tests.

 This is the task:

  desc Start mailserver on unprivileged ports
  task run-mailserver do
begin
  Java::Commands.java('com.ericdaugherty.mail.server.Mail',
 _('runtime/mailserver'),
:classpath = ['runtime/mailserver/lib',
 FileList['runtime/mailserver/lib/*.jar']]
)
rescue Exception
  # this is excepted, as java probably was interrupted via CTRL-C
end
  end


Generally speaking:

Thread.new do
   start your process 
end

This starts a new thread and returns control to your code (anything
following the end).  Meanwhile the thread can start a new process and will
end when the program returns.

The main thread will *not* block so you need some way of telling when the
process is ready to receive requests, and also some way of shutting it down
from at_exit.

Assaf


 Is it possible somehow to run this in the background during the tests? I
 had a look at the jetty stuff, but there the lifecycle is managed via
 URL communication...

 Thanx  cheers,
 Martin

Re: could buildr build a package made of various assemblies ?

[Assaf Arkin]

On Wed, Jul 8, 2009 at 2:11 PM, thierry henrio thierry.hen...@gmail.comwrote:

 Hi all, our company produce various and unstandardized assemblies :
 tar.bz2,
 zip
 each assembly has its own layout, and mainly consist in jar files
 there is no standardized repository to host jar files

 it is a real pain to make a runnable package, and yet it is required
 our customer are puzzled and so am I

 so, I would like to make a package made of bits of tar, zip, jar, text
 files
 I have no (more) java source to compile

 Following specification could apply

 given
 foo-1.1.tar.bz2 containing [foo-core-0.9.jar, foo-foo-1.1.jar]
 moo-2.3.zip containing [lib/moo-2.3.jar]
 when I package foomoo-2.3.1.zip
 then content is [lib-foo/foo-core-0.9.jar,
 lib-foo/foo-foo-1.1.jar, lib-moo/moo-2.3.jar]

 I failed to find in documentation whereas this is possible with buildr at
 this time


You can use the merge method to include the contents of one zip inside
another, but there's no support for merging tarballs into zips:

http://buildr.apache.org/packaging.html

Assaf




 Do you think buildr should be able to do that ?
 If not, do you know of any other library that could implement it ?
 If not, would you give some advice for code that could give me hints of
 implementation ?

 I hope this post is not totally irrelevant to this list

 Regards,
 Thierry

Re: How to run task in background

[Assaf Arkin]

On Fri, Jul 10, 2009 at 7:42 PM, Daniel Spiewak djspie...@gmail.com wrote:

 Shouldn't this still block the main thread under MRI?  Green threads don't
 allow for concurrent native dispatch.


If you run a process (system/tick/sh) then Ruby is just waits on the process
to complete, the thread is just sleeping and won't block other threads.

Assaf




 Daniel


 On Jul 10, 2009, at 9:39 PM, Assaf Arkin as...@labnotes.org wrote:

  On Fri, Jul 10, 2009 at 3:17 AM, Martin Grotzke 
 martin.grot...@javakaffee.de wrote:

  Hi,

 I have another one :)

 I want to start a mailserver with test.setup so that it's available for
 tests.

 I created a task that starts a simple java mail server which blocks
 until it's interrupted. Now I wonder how it's possible to run this in
 the background during the tests.

 This is the task:

 desc Start mailserver on unprivileged ports
 task run-mailserver do
  begin
Java::Commands.java('com.ericdaugherty.mail.server.Mail',
 _('runtime/mailserver'),
  :classpath = ['runtime/mailserver/lib',
 FileList['runtime/mailserver/lib/*.jar']]
  )
  rescue Exception
# this is excepted, as java probably was interrupted via CTRL-C
  end
 end


 Generally speaking:

 Thread.new do
   start your process 
 end

 This starts a new thread and returns control to your code (anything
 following the end).  Meanwhile the thread can start a new process and will
 end when the program returns.

 The main thread will *not* block so you need some way of telling when the
 process is ready to receive requests, and also some way of shutting it
 down
 from at_exit.

 Assaf


  Is it possible somehow to run this in the background during the tests? I
 had a look at the jetty stuff, but there the lifecycle is managed via
 URL communication...

 Thanx  cheers,
 Martin

Re: Tests not executed with eclipse bulding automatically - how to set different output folder for eclipse

[Assaf Arkin]

On Tue, Jul 7, 2009 at 3:09 PM, Alex Boisvert boisv...@intalio.com wrote:

 I'm not sure if test=all was designed this way on purpose... Assaf?

 Maybe we should consider test=force as a more intentioned command.



Buildr uses a timestamp to figure out if
there's a code change and only execute tests if it needs to:
https://issues.apache.org/jira/browse/BUILDR-139

Look for the file reports/last_successful_run -- if you delete it, the tests
will run again.  Also if any of the test dependencies are newer than that
file, but test dependency would be the target directory, I don't think it
checks every single .class file (expensive).


The test=all flag is for CI, where you want to force all the tests to run
regardless of errors (or other conditions).  Another option is to run test:*
which will forcefully run all the test that match *.

Assaf




 alex


 On Tue, Jul 7, 2009 at 2:50 PM, Martin Grotzke 
 martin.grot...@javakaffee.de
  wrote:

  Hi,
 
  I just tested this and it seems fine (in the buildfile I added
   options.test = :all) - great!
 
  However, I don't understand exactly why this does the trick. The website
  says:
 
  As you probably noticed, Buildr will stop your build at the first test
  that fails. We think it’s a good idea, except when it’s not. If you’re
  using a continuous build system, you’ll want a report of all the failed
  tests without stopping at the first failure. To make that happen, set
  the environment variable test to “all”, or the Buildr options.test
  option to :all.
 
  To me this does not explain, why it also solves our issue... Can you
  give some more explanation?
 
  Thanx  cheers,
  Martin
 
 
  On Tue, 2009-07-07 at 14:22 -0700, Alex Boisvert wrote:
   One idea:  You can force testing with buidlr test=all if that's what
  you
   want.
  
   alex
  
  
   On Tue, Jul 7, 2009 at 1:56 PM, Martin Grotzke 
  martin.grot...@javakaffee.de
wrote:
  
Hi Alex,
   
sorry I was not specific enough. What I meant is that we want to have
different output folders for eclipse and buildr.
   
So that buildr builds to what it does, and the output of eclipse goes
  to
e.g. eclipse-bin (both for classes, tests and resources). It just
  must
not build to the target dir(s) that buildr uses for the check, if
 tests
must be executed.
   
Again our original issue:
   
1 Write a test (that is ok) with eclipse, execute tests with buildr
 - test fails
2 Change the test with eclipse (having build automatically set) so
 that it fails, execute tests with buildr
 - tests are not executed
   
If eclipse does not have the build automatically set this issue
 does
not occur, but buildr executes the tests. I asume, that (in 2) the
compiled classes (by eclipse) are just up to date with the sources
 and
that is the reason why buildr does not run the tests.
   
Thanx  cheers,
Martin
   
   
On Tue, 2009-07-07 at 10:50 -0700, Alex Boisvert wrote:
 Hi Martin,

 I'm not sure I'm following the Eclipse task already generates
different
 output folders for classes/tests.

 e.g.

   classpathentry kind=output path=target/classes/
   classpathentry excluding=**/.svn/|**/CVS/
  output=target/resources
 kind=src path=src/main/resources/
   classpathentry excluding=**/.svn/|**/CVS/
output=target/test/classes
 kind=src path=src/test/java/
   classpathentry excluding=**/.svn/|**/CVS/
 output=target/test/resources kind=src
 path=src/test/resources/

 You could explain with a example highlighting current vs desired
behavior?

 alex


 On Tue, Jul 7, 2009 at 10:10 AM, Martin Grotzke 
 martin.grot...@javakaffee.de wrote:

  Hi,
 
  at first: we're just starting a new project here and it's the
 first
  for
  our company we're building with buildr - I'm very happy! :)
 
  Now my question: is it possible to specify a different output
  folder
for
  eclipse?
 
  We need this as we're using eclipse with Build automatically.
  This
  causes the effect, that tests that once ran successfully are not
  executed again, even if classes files or tests are changed.
 Turning
  off
  build automatically or a clean resolves this issue. However,
 we
  still want to have an automatic build in eclipse, so this is not
  the
  preferred solution.
 
  Is there another solution for this (e.g. specifying different
  output
  folder for eclipse)?
 
  Thx  cheers,
  Martin
 
 
   
  --
  Martin Grotzke
  http://www.javakaffee.de/blog/
 

Re: Buildr book

[Assaf Arkin]

On Fri, Jun 26, 2009 at 1:15 AM, Klaas Prause k...@blau.de wrote:

 What a shame, it is not on the german amazon site for sale. Do you have an
 idea when or if it will be sold outside the US?


I believe you can order it straight from the publisher and they'll ship
international:
https://www.createspace.com/3382199

If not, we'll figure something out.

This is the first book I'm self-publishing, still learning how it all
works. Apparently CreateSpace only lists the book on Amazon US. I'm trying
to figure out how to make it available in more book stores.

Assaf





 Regards Klaas

 -Ursprüngliche Nachricht-
 Von: matthieu.r...@gmail.com [mailto:matthieu.r...@gmail.com] Im Auftrag
 von Matthieu Riou
 Gesendet: Donnerstag, 25. Juni 2009 20:20
 An: users@buildr.apache.org
 Betreff: Buildr book

 Hi all,
 Assaf seems to be too shy to announce it so for those of you who wouldn't
 know yet, here it is:

 http://www.amazon.com/Buildr-Assaf-Arkin/dp/1442160942/

 It's mostly the pdf for the online documentation that Assaf has reformatted
 with love and care for the comfort of your eyes. So if you're more of the
 paper and ink type than bits and pixels, there's now a solution.

 Cheers,
 Matthieu

 P.S. So who updates the website?

Re: Ivy Extension for buildr 'ivy4r'

[Assaf Arkin]

On Wed, Jun 24, 2009 at 6:28 AM, Klaas Prause k...@blau.de wrote:

 Hi,



 we are using Ivy in our company for dependency management. To switch to
 buildr we still needed support for the ivy dependency system. It took some
 time but we finished a buildr extension for seamless integration of ivy into
 buildr. It also contains a Rake extension to publish our warbled ruby webapp
 wars to our ivy repository and deploy them from there.



 Just checkout github or rubyforge to use it:

 http://github.com/klaas1979/ivy4r/tree/master

 http://hamburgrb.rubyforge.org/



 The newest gem was build this morning so I am not sure that it is
 propagated to every mirror. The

 Documentation is still missing some examples and parts, if someone would
 like to use ivy drop me a note.



 The source is still beta, we are now starting to switch our projects from
 ANT to buildr, but it is working for us.


You're going to make a lot of friends with that :-)

Assaf






 Regards

 Klaas

Re: Help using Include

[Assaf Arkin]

On Wed, Jun 17, 2009 at 4:03 PM, Andrew Moore
andrew.mo...@redprairie.comwrote:

 Well, I have it working, but not as it seems like it should... I'm
 essentially excluding every other kind of file, like this:


 package(:war).path('').include(:from=_('../a/b/c')).exclude('**/*.gif').exclude('**/*.jpg').exclude('**/*.css')

 I've got about a dozen files I'm excluding, so this isn't a great solution.

 I am running version 1.3.3, so maybe there is a bug with that version
 related to this that has been fixed in 1.3.4.
 After looking more closely, it seems like with the other way:

 package(:war).path('').include(:from=_('../a/b/c')).include('**/*.js')


With the exception of merging zips, includes do not compose, so the first
include tells the path to include all the files from a/b/c, and the second
include tells path to include all the .js files in your build.

What's missing is a way to use :from but only for specific patten, something
like:

package(:war).include(**/*.js, :from='a/b/c')

I had to double check that there's no code for that, or an open issue (looks
like such an oversight). So first thing, let's add an issue.

Assaf



 I did seem to only get .js files, but I ended up with duplicate copies...
 one copy of all the .js files at the root of the war and another in the
 directory structure where I expect them to be.

 If I get time, I'll try and revisit this and create a test case example...
 I'm behind schedule right now, so I'll have to plug on with this. Thanks for
 the help, I will try and get back to this to flush it out.

 ~ Andrew

Re: Help using Include

[Assaf Arkin]

On Thu, Jun 18, 2009 at 11:12 AM, Ittay Dror ittay.d...@gmail.com wrote:



 Assaf Arkin wrote:

 On Wed, Jun 17, 2009 at 4:03 PM, Andrew Moore
 andrew.mo...@redprairie.comwrote:



 Well, I have it working, but not as it seems like it should... I'm
 essentially excluding every other kind of file, like this:



 package(:war).path('').include(:from=_('../a/b/c')).exclude('**/*.gif').exclude('**/*.jpg').exclude('**/*.css')

 I've got about a dozen files I'm excluding, so this isn't a great
 solution.

 I am running version 1.3.3, so maybe there is a bug with that version
 related to this that has been fixed in 1.3.4.
 After looking more closely, it seems like with the other way:

 package(:war).path('').include(:from=_('../a/b/c')).include('**/*.js')




 With the exception of merging zips, includes do not compose, so the first
 include tells the path to include all the files from a/b/c, and the second
 include tells path to include all the .js files in your build.

 What's missing is a way to use :from but only for specific patten,
 something
 like:

 package(:war).include(**/*.js, :from='a/b/c')

 I had to double check that there's no code for that, or an open issue
 (looks
 like such an oversight). So first thing, let's add an issue.


 isn't this what https://issues.apache.org/jira/browse/BUILDR-186 suggests?


Quite possibly adding this feature will also solve BUILDR-186.

Assaf




 ittay

  Assaf




 I did seem to only get .js files, but I ended up with duplicate copies...
 one copy of all the .js files at the root of the war and another in the
 directory structure where I expect them to be.

 If I get time, I'll try and revisit this and create a test case
 example...
 I'm behind schedule right now, so I'll have to plug on with this. Thanks
 for
 the help, I will try and get back to this to flush it out.

 ~ Andrew

Re: How to generate sources for/before compile

[Assaf Arkin]

On Fri, Jun 12, 2009 at 11:05 AM, Alex Boisvert boisv...@intalio.comwrote:

 On Fri, Jun 12, 2009 at 6:12 AM, Martin Grotzke 
 martin.grot...@javakaffee.de wrote:

  I needed to wrap the ant project with the generate = task ..., as
  otherwise (with just generate = ant('generate') do |ant| ...) the ant
  project was directly executed (AFAICS with the loading of the buildfile)
  and buildr complained with:
   Buildr aborted!
   Don't know how to build task 'Antwrap::AntProject[generate]'


 Ooops. I forgot ant() didn't yeld a task; it executes right away.

 Do you think the stuff above is ok, so that we could push this to the
  buildr howtos (wiki)? Or is there still room for improvement?


 I think the main improvement would be in wiring dependencies so the task
 only executes when needed.

 Here's a revised version,

 define generate-sources-example do

  # whatever you use to generate your sources
   sources = Dir[_(src/main/yak) + /**/*.yk]


sources = FileList[_(src/main/yak/**/*.yk)]

FileList, provided by Rake, is a better Dir. Also there's generally no need
to decompose and recompose paths.



  generate = file(path_to(:target, generated-source) = sources) do |dir|


likewise, file(_(target/generated-source)=sources)

Assaf



mkdir_p dir.to_s # ensure directory is created
# generate sources
# e.g.
# ant('generate') do |ant|
#  ...
# end
  end

  compile.from generate
 end

 I'm having issues creating the page in the wiki right now (confluence fails
 on me).  I'll create it when possible.

 alex

Re: Backwards-incompatible change in buildr 1.3.4: tasks/*.rake loaded after buildfile

[Assaf Arkin]

On Mon, May 11, 2009 at 9:38 AM, Rhett Sutphin rh...@detailedbalance.netwrote:

 Hi,

 In buildr 1.3.4, it appears that the contents of tasks/*.rake are evaluated
 after the buildfile itself.  This means that you can't use methods defined
 in extension .rake files in the top level of your buildfile, which worked in
 buildr 1.3.3.  Was this an intentional change?  Or should I file a bug?


Not intentional. I can't see it specified (or tested) anywhere. Rake loads
tasks/*.rake after the Rakefile, useful for breaking up big
Rakefiles; Buildr always loaded tasks/*.rake before the Buildfile, assuming
projects would use these. The raw_load_buildfile is adapted from Rake, and
lacking any tests, simply reverted to the Rake behavior.

Assaf




 I can provide more detail if needed.  (BTW, I apologize that I wasn't able
 to test this before now -- it appears to be a consequence of the fix for
 BUILDR-255, which I reported.)

 Thanks,
 Rhett

Re: Correct Way to Depend on Another Buildfile

[Assaf Arkin]

On Thu, May 7, 2009 at 8:18 AM, Daniel Spiewak djspie...@gmail.com wrote:

 Consider: http://github.com/djspiewak/gll-combinators

 Specifically, the examples/ directory defines a separate Buildr project
 which depends upon the project in its parent directory (gll-combinators).
  I
 could have done this by using two sub-projects, but I wanted a very
 specific
 directory organization.  In other words, I wanted the main sources to be
 under gll-combinators/src/main/scala/ while the examples are under
 examples/src/main/scala/.

 Currently, I'm handling this by actually shelling out to Buildr from within
 the examples/ buildfile, building the parent project and then explicitly
 adding its target/classes/ directory to the examples/ dependencies.  Is
 there a better way of doing this?  Better question: *shouldn't* there be a
 better way of doing this?  :-)


Yes.

Project definitions should be portable, so if you did everything by the
book, you should be able to import gll-combinators from within examples (or
the other way around). Some gotaches:

- You build now runs from a different directory, anything that assumes
relative paths is broken, but anything that uses _(..) will adjust. For
that, imported projects need to set their base_dir.
- Project references are relative, so if you have some 'master' project and
you import foo and bar, they can reference each other foo:module1,
bar:compA, etc.
- Globals may conflicts (and constants will warn you when they're redefined)
- Build settings (build.yml, profile.yml): you can only use one of these.

Generally easier (and from what I've heard more common) to start with the
outer buildfile and import nested buildfiles from its sub-directories. Would
be easier if everything we do only supports that, so let's use that as a
mental model for what you're doing.

From examples/buildfile:

- cd one level up, since you're effectively running the build from here.
- require gll-combinators, everything you do afterwards should extend it
- define the examples projects, base_dir should just point one level down
(since you're current dir is now one level up)

(You won't get tasks/build.yml/etc from the outer directory since the
directory change happens to late, but if the model works, we could make
Buildr do the right thing with some magic switch)

Assaf



 Optimally, I would like to just `require` the parent's buildfile and then
 using project('gll-combinators') to declare the dependency within the
 examples/ buildfile.  However, Buildr doesn't seems to have some global
 state relating to project definitions, meaning that this sort of thing
 doesn't work at present.





 Daniel

Re: Allow user to specify jmock dependency

[Assaf Arkin]

On Tue, Apr 21, 2009 at 1:19 PM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi,

 I just need to use jmock-2 instead of jmock-1, as I need to proxy a
 class (not interface).

 Is this a big deal?


http://buildr.apache.org/languages.html#java

Scroll down to the discussion about JUnit, also covers changing the version
of JMock.

Assaf




 There's an issue related to this:
 https://issues.apache.org/jira/browse/BUILDR-150

 Thanx  cheers,
 Martin

Re: question about Test task

[Assaf Arkin]

On Fri, Mar 27, 2009 at 2:42 PM, Alexis Midon alexismi...@gmail.com wrote:


 Hi guys,

 I have attached a simple HelloWorld project, with 2 modules, mod2 depends
 on mod1.
 When I test mod2, mod1 gets packaged. is that the expected behavior? I'd
 say no.


Does mod2 have mod1.jar as a classpath dependency?

Assaf




  ~/p/hello-dolly$buildr clean test
 (in /home/alexis/p/hello-dolly, development)
 Cleaning hello-dolly
 Testing hello-dolly
 Compiling hello-dolly:mod1 into
 /home/alexis/p/hello-dolly/mod1/target/classes
 Packaging hello-dolly-mod1-1.0.0.jar
 Compiling hello-dolly:mod2 into
 /home/alexis/p/hello-dolly/mod2/target/classes
 Testing hello-dolly:mod1
 Testing hello-dolly:mod2
 Compiling hello-dolly:mod2:test into
 /home/alexis/p/hello-dolly/mod2/target/test/classes
 Running tests in hello-dolly:mod2
 Trying to override old definition of datatype junit


 Alexis

Re: Update to site and documentation

[Assaf Arkin]

On Wed, Mar 18, 2009 at 5:52 AM, Alex Boisvert boisv...@intalio.com wrote:

 On Mon, Mar 16, 2009 at 3:57 PM, Assaf Arkin ar...@intalio.com wrote:

  Last week I switched our documentation system to use Jekyll[1]. Before
 the
  switch we used Docter to generate the Web site from Textile documents and
  HAML templates. Jekyll replaces that with Textile documents and Liquid
  templates.


 Nice work!  I'm happy to use a documentation system that has more traction
 while retaining the character of Docter.

 While on the subject of documentation, the Web site (and PDF) have two
  sections called Recipes and Troubleshooting. The Wiki has two sections
  called Buildr How Tos and Common Problems and Solutions. I'd like to
  consolidate both.


 My preference would be to keep them separate (recipes vs troubleshooting)
 since I think they are used under different situations.


That question didn't come out right.

We have Recipes and Buildr How Tos. I'd like to consolidate these.

We have Troubleshooting and Common Problems and Solutions. I'd like to
consolidate these.

That means out of the site/PDF and onto the Wiki.

Assaf




 The Wiki is much easier to edit than the Web site, so my preference right
  now is to consolidate these duplicates and move them over to the Wiki,
 with
  a link from the Web site navigation. Where it says Recipes right now it
  will
  say HowTo and link to the Wiki instead of another page on the site.


 Agreed.

 alex

Re: Mailing list archives Was: Welcome to Rebase Hell!

[Assaf Arkin]

On Thu, Mar 5, 2009 at 11:45 AM, Shane Witbeck sh...@digitalsanctum.comwrote:

 Is Google Groups not a contender?


Google Groups is an option.

Assaf




 -Shane


 On Thu, Mar 5, 2009 at 1:45 PM, Matthieu Riou matthieu.r...@gmail.com
 wrote:

  On Mon, Mar 2, 2009 at 10:05 AM, Alex Boisvert boisv...@intalio.com
  wrote:
 
   On Mon, Mar 2, 2009 at 9:59 AM, Assaf Arkin ar...@intalio.com wrote:
  
Speaking of, now that we're top-level and know our mailing lists,
 would
   be
cool to point people at usable mailing list archives (i.e. not
  Apaches).
Any
recommendations?
  
  
   MarkMail and/or Nabble.
  
 
  Yeah, they're both nice / broken in the same way. I tend to prefer
 markmail
  a bit though. Or if you're into the 90s look there's marc.info.
 
  Matthieu
 
 
  
   alex
  
 

Re: Welcome to Rebase Hell!

[Assaf Arkin]

On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak djspie...@gmail.com wrote:

 Those of you following development progress using Git are probably starting
 to notice that the classical Vic Master is no longer the all-knowing
 source of data.  Actually, Assaf's GitHub fork has become the more
 trustworthy one.  This is because upon its exit from incubation, Buildr
 gets
 to move its SVN repository to a new URL.  This is good for the project, but
 bad for the Git forks since git-svn stores the URL information in its
 commit
 messages.

 The solution of course is to re-clone from SVN, which I assume exactly what
 Assaf did.  There result is a repository which contains all of the same SVN
 commits as Vic's, but different messages and very different SHA1 revisions,
 meaning that Git has a much harder time merging between the two.  I
 discovered this when I attempted to merge Assaf's latest changes with my
 master (forked from Vic's).  57 conflicts later (all petty, little issues
 unrelated to my additions), I finally had a working master with the latest
 commits.  Unfortunately, when I cloned Assaf's repository directly and
 attempted to merge back some of my changes, it became very apparent that I
 would need to fix the issue in a more scientific manner.

 Long story short, the solution is to rebase all of your branches onto
 Assaf's master.  I did this by finding the exact commit where I diverged
 from vic (I had it tagged, actually) as well as the corresponding commit in
 Assaf's master.  These commits I tagged branch-point and
 new-branch-point, respectively.  Then for each branch, I did something
 like the following:

 git checkout scala-joint-compilation
 git rebase new-branch-point

 Once this was done, I went back to my master and performed a similar
 procedure:

 git checkout master
 git rebase -s ours new-branch-point

 This effectively wiped out all of my changes in that branch (it's possible
 that some commits may remain if you try it, but none did in my case).  Once
 this was done, I went and picked through my origin/master log to see what I
 was missing.  This meant re-merging all of my branches:

 git merge scala-joint-compilation
 git merge clojure
 ...

 Also, I had to cherry-pick a few commits that I had done on master (like
 four or five):

 git cherry-pick all-your-ant-base
 ...

 Once this was done, I pushed the result back to GitHub:

 git push -f origin

 The one caveat to this approach is I had all of my changes on numerous
 separate branches (for patching reasons).  All of these branches were
 branched off of the same point on vic/master.  Since there hadn't been any
 merging *between* the branches (only onto master), it was fairly easy to
 just rebase these branches onto the new trunk (I only had three conflicts
 in
 the whole process, all easily resolved).  Just judging by GitHub, not many
 people are managing their repositories in this fashion.  However, this does
 mean that you could be able to just rebase without the -s ours on your
 master and come to the same result.

 The point is that you will need to perform some conniptions of this sort in
 order to fix your repositories, otherwise your changes will remain
 incompatible with the Buildr mainline trunk: you won't be able to (easily)
 merge assaf/master, and he won't be able to (easily) pull from you.

 Incidentally, if anyone has a *better* way of doing this (particularly one
 where the entire master history doesn't get wiped out), I'm all ears!  I do
 still have the unmerged repository sitting in Time Machine, so I'm
 perfectly
 willing to roll-forward a copy and try again if the result turns out to be
 more correct.


Thanks.


AFAIK it's not possible to git svn clone directly from svn.apache.org due to
some weird restriction they placed on the SVN server, it will just keep
git-svn hanging forever. Somehow that doesn't affect incubator projects, or
svn.eu.apache.org, although my starting point was Jukka's unofficial but
somewhat official git mirror[1].


When you git log, check the git-svn-id:

commit a3ab30a66a092bf730950bd95a1394253ebd2f39

Author: Assaf Arkin as...@apache.org

Date:   Fri Feb 27 22:24:50 2009 +


 Fixed RDoc 2.3/2.4 conflict on rake setup.



git-svn-id:
https://svn.eu.apache.org/repos/asf/buildr/tr...@74872213f79535-47bb-0310-9956-ffa450edef68


If two repositories use a different URL -- look for http vs https,
svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr --
Git considers them distinct trees (branches). Any time you merge, Git will
have to merge the entire history of these two branches, leading to a lot of
conflicts.

So if you have branches with changes, follow Daniel's instructions. If you
don't, you can still use the -s ours strategy to switch from one branch to
another.

Until Apache comes with a better solution, I'm going to keep my
repository synchronized against  https://svn.eu.apache.org/repos/asf/buildr.
I suggest you all do the same, that way we have

Re: How to run a webapp in jetty

[Assaf Arkin]

On Fri, Feb 13, 2009 at 5:37 PM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi Daniel,

 thanx for your fast reply! At javaworld I found one relevant article
 ([1]), but this does only show (at least AFAICS) how to start jetty
 programmatically from java - what's not what I'm looking for. Am I
 missing s.th. in this article?


buildr jetty:start

This will start Jetty running in the current shell, and you can kill it with
Ctrl-C, or buildr jetty:stop (from a different shell). And of course you can
have your build finish by invoking this task (e.g. after packaging and
deploying the web app).

If the build does jetty:use, it either uses the running instance, or if
there is no instance, starts a new one and shut it down at the end (useful
for integration tests).

Assaf




 Thx  cheers,
 Martin


 [1]
 http://www.javaworld.com/javaworld/jw-12-2007/jw-12-outside-the-ide.html


 On Fri, 2009-02-13 at 19:04 -0600, Daniel Spiewak wrote:
  Nathan Hamblin has created a Buildr extension which accomplished
  this.  I don't have a URL handy, but he did publish it in a JavaWorld
  article.
 
  Daniel
 
  On Feb 13, 2009, at 6:37 PM, Martin Grotzke 
 martin.grot...@javakaffee.de
wrote:
 
   Hi,
  
   I have a simple webapp and want to run this with jetty.
  
   Just running buildr jetty:start (with require 'buildr/jetty' in my
   buildfile) starts jetty, but then jetty doesn't serve my webapp.
  
   From the ode buildfile I found the following:
  
task(start=[package(:war), jetty.use]) do |task|
  class  task ; attr_accessor :url, :path ; end
  task.url = http://localhost:8080/mywebapp;
  task.path = jetty.deploy(task.url, task.prerequisites.first)
  jetty.teardown task(stop)
end
  
task(stop) do |task|
  if url = task(start).url rescue nil
jetty.undeploy url
  end
end
  
   It seems that I can invoke this with buildr
   mywebapp:start (mywebapp
   beeing the name I defined for my project). I see jetty starting my
   webapp, but unfortunately it stops directly afterwards. This is the
   end
   of the output:
  
   
   [Completed] Your build has completed: /home/grotzke/proj/mywebapp
   buildr mywebapp:start
   Completed in 2.625s
   Undeploying app at /mywebapp
   Jetty server stopped
   
  
   So what is the correct way to run jetty with the deployed webapp?
  
   Thanx in advance,
   cheers,
   Martin
  
  
 

Re: How to run a webapp in jetty

[Assaf Arkin]

On Sun, Feb 15, 2009 at 8:26 AM, Martin Grotzke 
martin.grot...@javakaffee.de wrote:

 Hi Assaf,

 would you say [1] is the right way to run a webapp in jetty, or is there
 a better way?


I personally don't like the build to block, I like to have the shell ready
while the server is running in the background, so I recommend using
jetty:start.

Assaf




 Cheers,
 Martin


 [1] http://cwiki.apache.org/confluence/display/BUILDR/How+to+run+jetty



 On Sun, 2009-02-15 at 01:40 -0800, Assaf Arkin wrote:
  On Fri, Feb 13, 2009 at 5:37 PM, Martin Grotzke 
  martin.grot...@javakaffee.de wrote:
 
   Hi Daniel,
  
   thanx for your fast reply! At javaworld I found one relevant article
   ([1]), but this does only show (at least AFAICS) how to start jetty
   programmatically from java - what's not what I'm looking for. Am I
   missing s.th. in this article?
 
 
  buildr jetty:start
 
  This will start Jetty running in the current shell, and you can kill it
 with
  Ctrl-C, or buildr jetty:stop (from a different shell). And of course you
 can
  have your build finish by invoking this task (e.g. after packaging and
  deploying the web app).
 
  If the build does jetty:use, it either uses the running instance, or if
  there is no instance, starts a new one and shut it down at the end
 (useful
  for integration tests).
 
  Assaf
 
 
  
  
   Thx  cheers,
   Martin
  
  
   [1]
  
 http://www.javaworld.com/javaworld/jw-12-2007/jw-12-outside-the-ide.html
  
  
   On Fri, 2009-02-13 at 19:04 -0600, Daniel Spiewak wrote:
Nathan Hamblin has created a Buildr extension which accomplished
this.  I don't have a URL handy, but he did publish it in a JavaWorld
article.
   
Daniel
   
On Feb 13, 2009, at 6:37 PM, Martin Grotzke 
   martin.grot...@javakaffee.de
  wrote:
   
 Hi,

 I have a simple webapp and want to run this with jetty.

 Just running buildr jetty:start (with require 'buildr/jetty' in
 my
 buildfile) starts jetty, but then jetty doesn't serve my webapp.

 From the ode buildfile I found the following:

  task(start=[package(:war), jetty.use]) do |task|
class  task ; attr_accessor :url, :path ; end
task.url = http://localhost:8080/mywebapp;
task.path = jetty.deploy(task.url, task.prerequisites.first)
jetty.teardown task(stop)
  end

  task(stop) do |task|
if url = task(start).url rescue nil
  jetty.undeploy url
end
  end

 It seems that I can invoke this with buildr
 mywebapp:start (mywebapp
 beeing the name I defined for my project). I see jetty starting my
 webapp, but unfortunately it stops directly afterwards. This is the
 end
 of the output:

 
 [Completed] Your build has completed: /home/grotzke/proj/mywebapp
 buildr mywebapp:start
 Completed in 2.625s
 Undeploying app at /mywebapp
 Jetty server stopped
 

 So what is the correct way to run jetty with the deployed webapp?

 Thanx in advance,
 cheers,
 Martin


   
  

Re: is buildr still active?

[Assaf Arkin]

On Wed, Feb 11, 2009 at 11:32 AM, Ittay Dror itt...@tikalk.com wrote:



 Assaf Arkin wrote:

  Specs really really help. A patch could look simple and trivial, maybe
 it's
 a one line fix, but writing the spec and then accepting the patch is more
 work than accepting a tested patch.

 If you can't figure out how to fix something, but can at least write a
 spec
 to prove it's broken, that's also enormously helpful. The fix may end up
 to
 be trivial to someone else, just by running the spec and looking at the
 stack trace.

 So spec as much as possible.


 I find the current way of submitting patches / specs to be unproductive.
 It's hard for people to comment on a patch: you see an email about a patch,
 need to open the issue in the browser, download the patch, read, and then
 the only way to comment is writing an out-of-line comment in jira. and of
 course people follow jira notices far less than the regular mailing lists.
  Also, there are no clear coding conventions to follow. Finally, I don't
 remember seeing someone's patch being accepted.


I wonder how other people feel about it. I'd like to explore using Github to
review patches before submitting them through JIRA. You still need to have a
JIRA issue open, to track the issue, but review/commenting can be done
directly on the source. Possibly even pulling changes directly from a Git
repository, if you have a CLA.


We have about 14,000 lines of code in lib, additional 12,000 in spec, that's
a lot of convention. If you see something being used repeatedly, copy it. If
you see something inconsistent, fix it. If there's no precedence, I borrow
from Rails, RSpec, Rake in that order.

Assaf




 Ittay

 Assaf





 Ittay








 --
 Tikal http://www.tikalk.com
 Tikal Project http://tikal.sourceforge.net

Re: suggestions for separating unit vs. integration tests

[Assaf Arkin]

2009/2/6 Shane Witbeck sh...@digitalsanctum.com

 All,

 I've been trying to determine the best way to run unit tests vs.
 integration
 tests. It seems you only have the option of marking a project/component
 containing integration tests or not containing integration tests. Some of
 my
 projects have both unit and integration tests but I'd like to be able to
 control which get run. I'm aware of test=no and test.using :integration.
 The
 only option I can think of is creating a specific project just for the
 integration tests but I'd like to keep all the tests for a specific project
 together.

 Unless I'm missing something, I'd like to suggest a new feature to have
 explicit, finer grained control over running tests. Perhaps something along
 the lines of splitting the directory structure for tests:

 src/test/unit
 src/test/integration

 Could someone confirm my findings and/or suggest an alternative solution?


If you can figure out how to support two different test frameworks in the
same project (say JUnit and TestNG), then you're most of the way to having
unit tests and integration tests in the same project. I'm making this
parallel because I think two frameworks is easy to grasp for more people,
and also a lot more people interested in a feature that can do both.

Assaf




 Thanks,

 -Shane