I'm trying to run an ant script on Linux using ant-contrib.
I specify the jar using ant's -lib parameter, but it doesn't seem to be detected.
This is the warning I get:
[taskdef] Could not load definitions from resource net/sf/antcontrib/antcontrib.properties. It could not be found.
And the command I run is:
ant -lib ./lib/ant-contrib.jar -f build-master.xml
I also tried specifying the absolute path, but no success.
Finally figured out that it was a problem with ant itself. The environment I was using had ant 1.9.2 installed. As soon as I upgraded to 1.9.6, the lib parameter started to work!
I have run into an ERROR with SBT today. It can best be shown with the sbt sbt-version command:
Run on 5/29/17:
eric#linux-x2vq:~$ sbt sbt-version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=256M; support was removed in 8.0
[info] Set current project to eric (in build file:/home/eric/)
[info] 0.13.13
Run on 6/1/17:
eric#linux-x2vq:~$ sbt sbt-version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=256M; support was removed in 8.0
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:233)
at jline.UnixTerminal.<init>(UnixTerminal.java:64)
at jline.UnixTerminal.<init>(UnixTerminal.java:49)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:209)
at jline.TerminalFactory.create(TerminalFactory.java:100)
at jline.TerminalFactory.get(TerminalFactory.java:184)
at jline.TerminalFactory.get(TerminalFactory.java:190)
at sbt.ConsoleLogger$.ansiSupported(ConsoleLogger.scala:123)
at sbt.ConsoleLogger$.<init>(ConsoleLogger.scala:117)
at sbt.ConsoleLogger$.<clinit>(ConsoleLogger.scala)
at sbt.GlobalLogging$.initial(GlobalLogging.scala:43)
at sbt.StandardMain$.initialGlobalLogging(Main.scala:64)
at sbt.StandardMain$.initialState(Main.scala:73)
at sbt.xMain.run(Main.scala:29)
at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)
at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)
at xsbt.boot.Launch$.run(Launch.scala:109)
at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)
at xsbt.boot.Launch$.launch(Launch.scala:117)
at xsbt.boot.Launch$.apply(Launch.scala:18)
at xsbt.boot.Boot$.runImpl(Boot.scala:41)
at xsbt.boot.Boot$.main(Boot.scala:17)
at xsbt.boot.Boot.main(Boot.scala)
[info] Set current project to eric (in build file:/home/eric/)
[info] 0.13.13
No changes (that I know of) to either my SBT or Java setup.
Any ideas on what might be causing this or how to fix the error?
Thank you!
I had the same issue, especially when the TERM environment variable is set to xterm-256color. Setting it to a different value fixed the issue for me, e.g.
export TERM=xterm-color
I found the package which causes this issue: ncurses. I downgraded ncurses to version ncurses-6.0+20170429-1 (I am using Arch Linux) and SBT starts just fine.
Steps for Arch Linux:
cd /var/cache/pacman/pkg
sudo pacman -U ncurses-6.0+20170429-1-x86_64.pkg.tar.xz # or some other older version
Steps for Mac: see https://github.com/jline/jline2/issues/281
I think this issue was introduced with ncurses version 20170506, see: http://invisible-island.net/ncurses/NEWS.html#index-t20170506
+ modify tic/infocmp display of numeric values to use hexadecimal when
they are "close" to a power of two, making the result more readable.
I filed an issue on the SBT issue tracker: https://github.com/sbt/sbt/issues/3240
Edit: SBT version 0.13.16 includes the fix for this problem.
You can add export TERM=xterm-color to the top of /usr/share/sbt/bin/sbt because $HOME/.sbtconfig is deprecated.
sbt command is just a script. It load $HOME/.sbtconfig at the very beginning, so just put
export TERM=xterm-color
as #user3113045 said in the conf file, sbt will work. In that case your other term commands will still use xterm-256color.
This resolved the issue in my case (Linux Users):
Open your terminal
Navigate to your project directory
type "export TERM=xterm-color" in your terminal without the quotes
Hit ENTER
That is all and then you are good to go.
One year passed... now it happened to me.
So, ncurses did change, and the corresponding sbt part was ...I guess... probably only implemented based on random guessed tests and observations/bugs and not any spec nor RFC. (So far, sbt is the only program with this ncurses issue that I know of.)
In case you can't simply upgrade sbt nor downgrade ncurses, you could change the TERM environment variable as mentioned in the other answers.
trivial fix:
If your sbt script is some bash script (most likely, unless you run DOS' .bat files)
$ file /usr/bin/sbt
/usr/bin/sbt: Bourne-Again shell script, ASCII text executable
, then it might suffice to add this workaround:
TERM="${TERM/xterm-256color/xterm-color}"
If you can, change sbt version in build.properties to higher. 13.16 work for me.
For Ubuntu 20.04 Users, Open your terminal and run the bellow CMDs
Go to this "/usr/share/sbt/bin" directory ( $ cd /usr/share/sbt/bin )
give the permission to edit file ( $ sudo chmod -R 777 sbt )
Open the sbt text file in this directory ( $ nano sbt )
Add this "export TERM=xterm-color" cmd in top and save ( Ctrl + X )
Ex:-
#!/usr/bin/env bash
export TERM=xterm-color
set +e
I can't write a comment as my score is too low, but user3113045's answer worked when I added export TERM=xterm-color to my .zshrc file
I faced this issue when i am using activator which uses sbt internally.
I am using Ubuntu and this error was frustrating me.
I started facing this issue when i ran
$ activator gen-idea (tool which as per the intellij is legacy)
After this i tried to delete all the cache that this tool generated.
I deleted the .ivy and .sbt directories from my home folder and ran the activator cleanFiles compile command which resolved my issue.
I currently have a command line sbt -Dsome.configuration.option test doing what I want, but I would like it to apply that configuration option automatically for sbt test (and no other sbt phase). If my terminology is correct, then I want to set a Java Option for the Test Configuration. How do I do this?
Searching on these terms has led me to http://www.scala-sbt.org/release/docs/Testing.html but I have not yet been able to understand it.
This question looks similar to mine: Define custom test configurations in sbt
Try this:
testOptions in Test +=
Tests.Setup(() => sys.props += "some.configuration.option" -> "true")
Caveat:
Because you're not forking this mutates the state of the system property in the JVM running sbt itself.
Which means that after running test the first time it that system property will also be set if you, for instance, run your main from within sbt (run/runMain).
I use sbt with the native packager plugin, in order to build Debian packages for our Play 2.2 applications. We use the debian:publish in order to upload the packages to our Artifactory server, and the publish command to publish the regular Java jars.
I'd like to be able to use the regular publish command to published both the jar files and the Debian packages. I think I need to somehow combine the publish task in the Debian scope with the regular one in the Compile scope, but I can't really find any documentation on how to do that.
I came up with the following code, which works, but seems to me to be the 'wrong' way to do it:
publish := { // Also publish deb files
val value = publish.value
(publish in Debian).value
}
Especially the second line seems wrong, since it's ignoring the value. The val is there to quiet a warning, which is another smell.
Is there a better way to do this?
You can use triggeredBy. In your build.sbt add following line:
publish in Debian <<= (publish in Debian).triggeredBy(publish in Compile)
PS. I think the way you did it is also fine. If you're worried about the warning you can assign the result to some val.
Here, the dependsOn task is appropriate, if you don't care about the return value:
publish := publish.dependsOn(publish in Debian).value
Using Flyway 2.3 on Windows, same result from command prompt and within cygwin. Production env is Linux, but haven't been able to test there yet.
My SQL file has the line:
alter table person add ${new_col} text;
I added the following to my build.sbt, based on what I saw on the the flyway sbt doc page:
flywayPlaceholders := Map(
"new_col" -> "temp_name"
)
When I run
> sbt flywayMigrate
I get this:
com.googlecode.flyway.core.api.FlywayException: No value provided for placeholder expressions: ${new_col}. Check your configuration!
Under cygwin it does work if I specify the substitution on the command line:
> sbt flywayMigrate -Dflyway.placeholders.new_col=temp_name
Command line plaveholder substitution doesn't work in Windows command prompt, but I suspect that's a different issue as none of my -D options are respected there.
I'm new to both sbt and Flyway, so I'm hoping this is something simple, but I couldn't find anything helpful by googling. thanks in advance for any help
The flywayPlaceholders in build.sbt are currently by the commandline configuration.
This is a bug in Flyway.
I created a pull request.