In my project, I have exactly one dependency (right now, it's early!) - Hibernate. In my Ivy config, I have the following:
<dependencies>
<!-- https://mvnrepository.com/artifact/org.hibernate/hibernate-core -->
<dependency org="org.hibernate" name="hibernate-core" rev="5.4.0.Final" conf="sources->sources"/>
<dependency org="org.hibernate" name="hibernate-core" rev="5.4.0.Final" conf="binaries->default"/>
</dependencies>
And in my build.xml, I have this:
<ivy:retrieve conf="sources" pattern="war/WEB-INF/lib/[conf]/[artifact](-[classifier]).[ext]"/>
<ivy:retrieve conf="binaries" pattern="war/WEB-INF/lib/[artifact](-[classifier]).[ext]"/>
Now, in my lib folder, I have a folder called sources with exactly one jar, hibernate-core-sources.jar - perfect!! But in the lib folder itself, I don't have exactly one jar - I have 18 jars, one for each of Hibernate's dependencies (and grandparent dependencies, etc.)
What I'd really like to see is something like hibernate-core.jar and hibernate-core-deps.jar.
Is something like this possible? If it isn't, would it be possible to have it be hibernate-core.jar and my-app-deps.jar? And if THAT isn't possible, can it just bundle it all into a single my-app-deps.jar?
I'm not very experienced with Ivy, so the more explicit your answer, the better!
It's possible, but you have to be aware that when you build the classpath you may end um missing some classes and having NoClassDefFoundError thrown at runtime.
The solution is to call ivy resolve once with transitive set to false, and second time with it being set to true (which is default). After each of these you have to call retrieve but with different retrieve patterns, so the non-transitive (hibernate-core.jar) to lib folder and transitive to a temp folder from which you could create hibernate-core-deps.jar.
i am in a scenario that the artifacts are published to a local maven repository with both both pom file and ivy file. I am trying to access this repository by treating it as an ivy repo, as a result, I had to set m2compatible=true so that the resolvers can correctly identify the path pattern.
sbt allows one to override the default list of resolvers through the following properties:
-Dsbt.override.build.repos=true -Dsbt.repository.config=<path to sbt repository file>
The foramt of the repository file is something like the following,
[repositories]
local
my-artifacts: http://my.artifact.proxyserver.com/artifacts/,[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
maven : http://my.artifact.proxyserver.com/artifactory/maven-central
My question is how am I able to specify m2compatible=true for the resolver "my-artifacts" in the above file? Because without that setting, if I depend on
com.google.common % guava % 23.1
the resolver will look for the path:
com.google.common/guava/23.1
instead of
com/google/common/guava/23.1
sbt allows to add mavenCompatible towards the end of an ivy resolver.
I have a test-suite that contains several files and folders with test data. Some of the files have repeated names in different folders.
In SBT I have a task to generate the resources downloading the resources and uncompressing them in a folder.
The build.sbt file (simplified) is:
import sbt._
import sbt.Keys._
resourceGenerators in Test += Def.task {
val shaclTests = url("https://github.com/w3c/data-shapes/raw/gh-pages/data-shapes-test-suite/tests.zip")
IO.unzipURL(shaclTests, resourceManaged.value / "test-suite" ).toSeq
}.taskValue
when I execute sbt test I obtain:
[error] (test:copyResources) Duplicate mappings:
[error] C:\src\pruebas\duplicates-sbt\target\scala-2.10\test-classes\manifest.ttl
[error] from
[error] C:\src\pruebas\duplicates-sbt\target\scala-2.10\resource_managed\test-suite\tests\manifest.ttl
...
which complains that the manifest.ttl file is duplicated.
If I remove the duplicated files it works, however, I think it should be possible to have duplicate file names in different folders.
I have found some related issue here but although I tried to use crossTarget instead of resourceManaged it still doesn't work.
I also found this question that may be related, but it is about generating assemblies and the solution doesn't seem to apply.
what is the reason SBT won't allow me to have dependencies between different configurations of different projects in a multi-project build?
consider the following setup in the main build.sbt file:
lazy val domain: Project = project in file("domain") dependsOn(testUtils % "test->test")
lazy val testUtils: Project = project in file("testUtils") dependsOn(domain % "compile->test")
...
I would want to write all my test helpers in testUtils, and have each of the other projects' test code to be clean test logic without the (sometimes duplicated among different projects) boilerplate of the aiding methods.
SBT is forcing me to put the : Project type, since it complains the value is "recursive". and upon reloading, I get:
...
at $281429c805669a7befa4$.domain(build.sbt:142)
at $281429c805669a7befa4$.testUtils$lzycompute(build.sbt:144)
at $281429c805669a7befa4$.testUtils(build.sbt:144)
at $281429c805669a7befa4$.domain$lzycompute(build.sbt:142)
at $281429c805669a7befa4$.domain(build.sbt:142)
[error] java.lang.StackOverflowError
[error] Use 'last' for the full log.
is there a way around this? or should I write test-related logic in each module test, even at the cost of getting the code less organize, many "test->test" dependencies, etc'...
I'd like to configure Typesafe Activator and it's bundled tooling not to use my user home directory - I mean ~/.activator (configuration?), ~/.sbt (sbt configuration?) and especially ~/.ivy2, which I'd like to share between my two OSes.
Typesafe "documentation" is of little help.
Need help for both Windows and Linux, please.
From Command Line Options in the official documentation of sbt:
sbt.global.base - The directory containing global settings and plugins (default: ~/.sbt/0.13)
sbt.ivy.home - The directory containing the local Ivy repository and artifact cache (default: ~/.ivy2)
It appears that ~/.activator is set and used in the startup scripts and that's where I'd change the value.
It also appears (in sbt/sbt.boot.properties in activator-launch-1.2.1.jar) that the value of ivy-home is ${user.home}/.ivy2:
[ivy]
ivy-home: ${user.home}/.ivy2
checksums: ${sbt.checksums-sha1,md5}
override-build-repos: ${sbt.override.build.repos-false}
repository-config: ${sbt.repository.config-${sbt.global.base-${user.home}/.sbt}/repositories}
It means that without some development it's only possible to change sbt.global.base.
➜ minimal-scala activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2 about
[info] Loading project definition from /Users/jacek/sandbox/sbt-launcher/minimal-scala/project
[info] Set current project to minimal-scala (in build file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/)
[info] This is sbt 0.13.5
[info] The current project is {file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/}minimal-scala 1.0
[info] The current project is built against Scala 2.11.1
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
If you want to see under the hood, you could query for the current values of the home directories for sbt and Ivy with consoleProject command (it assumes you started activator with activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2):
> consoleProject
[info] Starting scala interpreter...
[info]
import sbt._
import Keys._
import _root_.sbt.plugins.IvyPlugin
import _root_.sbt.plugins.JvmPlugin
import _root_.sbt.plugins.CorePlugin
import _root_.sbt.plugins.JUnitXmlReportPlugin
import currentState._
import extracted._
import cpHelpers._
Welcome to Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_60).
Type in expressions to have them evaluated.
Type :help for more information.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/.ivy2
Iff you're really into convincing Activator to use sbt.ivy.home, you have to change sbt/sbt.boot.properties in activator-launch-1.2.2.jar. Just follow the steps:
Unpack sbt/sbt.boot.properties out of activator-launch-1.2.2.jar.
jar -xvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
Edit sbt/sbt.boot.properties and replace ivy-home under [ivy].
ivy-home: ${sbt.ivy.home-${user.home}/.ivy2}
Add the changed sbt/sbt.boot.properties to activator-launch-1.2.2.jar.
jar -uvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
With the change, -Dsbt.ivy.home=./ivy2 works fine.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/ivy2
I was experimenting with this today. After a while, it seems to me like this could be the best thing to do:
Windows:
setx _JAVA_OPTIONS "-Duser.home=C:/my/preferred/home/"
Linux:
export _JAVA_OPTIONS='-Duser.home=/local/home/me'
Then you should be good to go for any Java Program that wants to store data in your home directory.
As an addition to Jacek's answer, another way that worked for me to set the .ivy2 directory was to use the sbt ivyConfiguration task. It returns configuration settings related to ivy, including the path to the ivy home (the one which defaults to ~/.ivy2).
Simply add these few lines to the build.sbt file in your project :
ivyConfiguration ~= { originalIvyConfiguration =>
val config = originalIvyConfiguration.asInstanceOf[InlineIvyConfiguration]
val ivyHome = file("./.ivy2")
val ivyPaths = new IvyPaths(config.paths.baseDirectory, Some(ivyHome))
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.log)
}
It returns a new ivy configuration identical to the original one, but with the right path to the ivy home directory (here ./.ivy2, so it'll be located just next to the build.sbt file). This way, when sbt uses the ivyConfiguration task to get the ivy configuration, the path to the .ivy2 directory will be the one set above.
It worked for me using sbt 0.13.5 and 0.13.8.
Note: for sbt versions 0.13.6 and above, the construction of the InlineIvyConfiguration needs an additional parameter to avoid being flagged as deprecated, so you might want to change the last line into :
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.updateOptions, config.log)
(note the additional config.updateOptions)
I had that same problem on Mac. I erased the directory in user home directory named .activator and all related folder. After that run activator run command on terminal. Activator download all of the folder which I deleted. Than problem solved.