Hi Ara, Looks like a regression that was introduced in Buildr 1.4.2; it's not specific to Scala but it will get triggered if packaging a war with scala.
I've now fixed the issue in trunk: https://issues.apache.org/jira/browse/BUILDR-527 If you don't want to upgrade to trunk, you can add the following to your buildfile as a temporary workaround: # workaround until Buildr 1.4.3 package(:war).libs.map! { |lib| lib.is_a?(String) ? file(lib) : lib} Thanks for reporting the issue! We'll be releasing Buildr 1.4.3 within the next two weeks. alex On Sat, Oct 9, 2010 at 9:14 AM, Ara Vartanian <[email protected]>wrote: > I'm having trouble packaging a minimal package(:war) project using > Scala 2.8 and buildr 1.4.2 and JRuby 1.5.3. When I run a 'buildr > package', an exception is thrown: > > (in C:/Users/Ara/scala/foo3, development) > Building foo3 > Packaging foo3 > Buildr aborted! > NoMethodError : undefined method `invoke' for #<String:0x65ebba10> > > A simple run of 'buildr' builds with no problem. > > (in C:/Users/Ara/scala/foo3, development) > Building foo3 > Completed in 0.137s > > The wrinkle seems to be that I have a single file foo.scala in the > src/main/scala folder. If I delete that file, the 'buildr package' > command returns without exception, building a simple, "empty" war. The > contents of 'foo.scala' are simply: > > object Foo {} > > So I'm inferring that invoking the Scala compiler is tripping up the > war packaging, but I can't figure much out beyond that. I've attached > a zip of the project, which is a whopping 2kb. > > The contents of my buildfile are: > > VERSION_NUMBER = "1.0.0" > GROUP = "foo3" > COPYRIGHT = "" > require 'buildr/scala' > > desc "The Foo3 project" > define "foo3" do > project.version = VERSION_NUMBER > project.group = GROUP > manifest["Implementation-Vendor"] = COPYRIGHT > resources > compile.with > test.with > package(:war) > end > > Let me thank anyone in advance for any help they would have on this. > > -- Ara Vartanian >
