How to change destination jar directory - sbt

How to change destination directory of jars getting downloaded by sbt in libraryDependencies.
I want to change it to some thing like $HOME/custom_jars rather than its default one ($HOME/.ivy2/....)
Thanks,
Abhinandan

Setting retrieveManaged to true causes sbt to create a lib_managed directory in your project directory and to put your dependency jars there.
The directory name is used is controlled by managedDirectory and defaults to baseDirectory.value / "lib_managed", but you can set it to something else if you like.

Related

What's diff between paches and plugins

I change the code in repo carbon-apimgt, and i run command "mvn clean install -Dmaven.test.skip=true" , I get a jar from target, what's next to apply this change?
Plugins directory is where we keep all the jars of components that are used in the product. Patches directory is used to track the changes done to each jar. What it does is, when you add a directory (eg: patch0001/) and add a jar to this new directory (eg: patch0001/org.wso2.carbon.apimgt.api_9.0.174.jar), this will replace the same-named jar that is found in the plugins directory.
Before this replacement, the server will first backup all the jars that are found in the plugins directory to a new folder patch0000 inside the patch folder.
At each startup, server will first apply the jars in the patch0000 directory and start replacing the jars by increasing the counter of each patch folder. (eg: patch0000, then patch0001, patch0002 up to patch9999).
This is the difference between the plugins directory and patch directory. If you replace a jar in the plugins directory, this is not a backward compatible change. However, if you replace a jar using this patch mechanism, whenever you remove the patch0001 directory from the system, this change will be reverted and the original jar will be preserved.

Set sbt options in build.sbt

I'm working on an SBT project that has to be built with the options like:
-Xmx2G -Xss256M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
This means that every new developer has to read the readme and assign the options to SBT_OPTS in bash profile or put them in the sbtopts file. Similarly, this has to be configured on Jenkins and this applies to all the projects (so if someone wants to use -XX:+UseG1GC with other projects it becomes an issue). Is it possible to specify the required options in the build file itself? This seems logical to me, as the options are project-specific and without them, you cannot build the project.
Create a .sbtopts file at the root of the build with contents:
-J-Xmx2G
-J-Xss256M
-J-XX:+UseConcMarkSweepGC
-J-XX:+CMSClassUnloadingEnabled

How to set jshint/jsxhint "esnext" option in Atom

I am using Atom's linter, react, and linter-jshint/linter-jsxhint.
In my JSX files, I keep getting the warning
Warning: 'import' is only available in ES6 (use esnext option). (W119)
That's pretty straightforward. I did some searching, and found that this can be set under the jshintConfig option in package.json (when using NPM). My project uses NPM and I have a package.json. I added:
"jshintConfig": {
"esnext": true
}
After that, I did a reload but the warnings persist. I also modified my linter-jshint/linter-jsxhint config in Atom (config.cson) with:
"linter-jshint":
harmony: true
esnext: true
"linter-jsxhint":
harmony: true
esnext: true
And did a reload but that didn't help it either.
So: when using linter-jshint/linter-jsxhint as Atom packages, how to I set the esnext option?
You can create a .jshintrc in your project folder, it will be read by the linter as a json source file.
To use esnext option,
{
"esnext": true
}
You will probably need to reopen your JS file to be able to see the new changes.
First possibility, recommended : you can create a .jshintrc in you home directory and jshint will read it in case there is none in the project directory. You might need to restart Atom after.
Another possibility not recommended : you could also change the config of jshint in Atom and specify the location of your global .jshintrcif for some reason you don't want to put it in your home directory with the flag --config
'linter-jshint':
'jshintExecutablePath': /path/to/jshint --config /path/to/.jshinrc
Run 'which jshint' to find the path.
It is not recommended because every other .jshinrc file (in the project, etc.) will be ignore:
jshint will look for this configuration in a number of locations, stopping at the first positive match:
The location specified with the --config flag
A file named package.json located in the current directory or any parent of the current directory (the configuration should be declared as the jshintConfig attribute of that file's JSON value)
A file named .jshintrc located in the current directory or any parent of the current directory
A file named .jshintrc located in the current user's "home" directory (where defined)
You can use the inline configuration adding this comment in your file .js:
/* jshint esversion: 6 */
http://jshint.com/docs/

Why is sbt current project name "default" in 0.10?

I'm using sbt 0.10 to build a Scala project using just a build.sbt file instead of a full configuration.
Every time I start sbt it gives me the messages as follows:
[info] Set current project to default-ee699e (in build file:/Users/.../project/plugins/)
[info] Set current project to default-8febe7 (in build file:/Users/.../)
I did set the name and mainClass settings in the build.sbt file, so I don't know what I need to set to get the project names default-XXXX go away.
EDIT: the answer given below is correct in that this is cosmetic. If you switch to a full configuration of sbt, then it uses that project's name as opposed to default-XXXX however.
The message can be a bit misleading, it's not saying that you must "set the curent project", it's telling you what it's doing.
It sets the current project to the plugins folder, does it's stuff (compile, etc.), then sets the current project to your actual build folder and does it's thing once again.
You don't need to set anything else.

Qmake does not support build directories below the source directory

I have created an application that compiles and runs like a charm on OS-X. I would now like to start getting it to work on Windows. To start, I copied the project to a windows machine and just tried to compile, but got this error:
:: warning: Qmake does not support build directories below the source directory.
Any ideas?
Set the shadow build directory to some folder on the same level of your project directory:
folder/
project/
project-shadow-build-release/
project-shadow-build-debug/
You can do this in the "Projects" view, via the toolbar on the left. To me, this warning was just an annoyance, a project never failed to build because of it.
Don't copy your project.pro.user file when you are copying a project from one machine to another, or from one directory to another. When you open the project, Qt Creator will offer to create a new build directory in the proper place.
Andref gave the correct answer to resolve this warning, but you may want to understand why this requirement exists.
In fact, the build directory must be at the same folder level as the project (i.e. it can't be above or below). The reason why is that the linker is called from the build directory. Hence, any relative paths to library files will be different than what you entered in your project file.
It kinda sucks. I like to put all intermediate files in their own folder. But you simply can't with qmake.
.pro.user are generated files by Qt Creator. They are unrelated to qmake and should not be touched (and not put into a VCS for that matter)
Just remove the files with the pro.user extension , worked for me
I also got this, trying to compile a project created on linux.
Another way to solve it is to change the paths in the .pro.user file (in the directory of your project)
Right Click on a project: Set As Active Project
Click on the Projects button (The one with the spanner image)
Edit build configuration : Debug / Profile / Release / and change the default directories, OR just uncheck the Shadow build check box.
The Build directory path should now change to black, from red

Resources