I'm trying to use jooq-sbt-plugin to generate some code.
I downloaded the code, compiled it and copied jar into lib directory, but on sbt load i get this error:
[warn] Note: Some unresolved dependencies have extra attributes. Check that th
ese dependencies exist with the requested attributes.
[warn] sean8223:jooq-sbt-plugin:1.4 (sbtVersion=0.13, scalaVersion=2.10
)
in project/plugins.sbt i have this
resolvers += Resolver.file("lib-repo", file("lib")) transactional()
addSbtPlugin("lib-repo" %% "jooq-sbt-plugin" % "1.4")
Is this plugin "detected" and cannot be loaded or sbt does't see it?
P.S.
By default plugin does not work because it depends on jooq-3.2.1 which is not available on maven and I get error - unresolved dependencies. According to plugin readme i could set jooqVersion in build.sbt to other version, but this doesn't seem to work.
In my project/plugins.sbt:
resolvers += "sean8223 Releases" at "https://github.com/sean8223/repository/raw/master/releases"
addSbtPlugin("sean8223" %% "jooq-sbt-plugin" % "1.3")
In my build.sbt:
seq(jooqSettings:_*)
jooqVersion := "3.3.1"
And everything is successfully resolved. I didn't run any tasks, but since you say that the problem is in resolving jooq, show your build.sbt if it still doesn't work for you.
Related
I published some libraries using sbt publishLocal it worked and published to my ~/.ivy2/local dir.
I then have a project that depends on these libraries but sbt update can't find them.
specifically, my project has these dependencies:
lazy val myDependencies = commonDependencies ++ Seq(
"my.corp" %% "lib1" % "1.0.1-SNAPSHOT" withSources () withJavadoc (),
"my.corp" %% "lib2" % "2.0.2-SNAPSHOT" withSources () withJavadoc ()
)
sbt update has this error:
[error] (services / update) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
[error] file:////home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar: not found: /home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar
[error] file://///home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar: not found: /home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
when I look in the dir I can see the published jars but their name has the scala version appended, which is why the update resolving fails, I think :
$ ls /home/myuser/.ivy2/local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars
lib1_2.12.jar lib1_2.12.jar.md5 lib1_2.12.jar.sha1
$ ls /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars
lib2_2.12.jar lib2_2.12.jar.md5 lib2_2.12.jar.sha1
If I publish to a repo for real I can resolve the libs.
Does anyone know the sbt incantation to fix this? ;-)
Cheers
Karl
Update:- I think coursier is the problem, not sure how to tell it to look for lib2_2_12.jar. Could it have a bad cached reference?
Caused by: lmcoursier.internal.shaded.coursier.cache.ArtifactError$NotFound: not found: /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
Update:-
disabling coursier worked
from the sbt REPL I can run
sbt:my-project> set ThisBuild / useCoursier := false
and then
sbt:my-project> update
and that worked, but setting it back to true update failed again, so this looks like a coursier issue.
Update:
coursier fetch from the command line worked!!
coursier fetch my.corp::lib1:1.0.1-SNAPSHOT --no-default -r central -r ivy2Local
downloaded the transitive dependencies and found my jar in my local ivy2 dir
so this is back to looking like an sbt - coursier interaction issue
I've just now run into this and after lots of diffs between an older working version and this non-working version I figured out that it is the withSources() that triggers the bug in sbt and/or coursier.
I'm attempting to use the sbt-aspectj plugin with the sbt native packager and am running into an issue where the associated -javaagent path to the aspectj load time weaver jar references an ivy cache location rather than something packaged.
That is, after running sbt stage, executing the staged application via bash -x target/universal/stage/bin/myapp/ results in this javaagent:
exec java -javaagent:/home/myuser/.ivy2/cache/org.aspectj/aspectjweaver/jars/aspectjweaver-1.8.10.jar -cp /home/myuser/myproject/target/universal/stage/lib/org.aspectj.aspectjweaver-1.8.10.jar:/home/myuser/myproject/target/universal/stage/lib/otherlibs.jar myorg.MyMainApp args
My target platform is Heroku where the artifacts are built before being effectively 'pushed' out to individual 'dynos' (very analogous to a docker setup). The issue here is that the resulting -javaagent path was valid on the machine in which the 'staged' deployable was built, but will not exist where it's ultimately run.
How can one configure the sbt-aspectj plugin to reference a packaged lib rather than one from the ivy cache?
Current configuration:
project/plugins.sbt:
addSbtPlugin("com.typesafe.sbt" % "sbt-aspectj" % "0.10.6")
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.1.5")
build.sbt (selected parts):
import com.typesafe.sbt.SbtAspectj._
lazy val root = (project in file(".")).settings(
aspectjSettings,
javaOptions in Runtime ++= { AspectjKeys.weaverOptions in Aspectj }.value,
// see: https://github.com/sbt/sbt-native-packager/issues/598#issuecomment-111584866
javaOptions in Universal ++= { AspectjKeys.weaverOptions in Aspectj }.value
.map { "-J" + _ },
fork in run := true
)
Update
I've tried several approaches including pulling the relevant output for javaOptions from existing mappings, but the result is a cyclical dependency error thrown by sbt.
I have something that technically solves my problem but feels unsatisfactory. As of now, I'm including an aspectjweaver dependency directly and using the sbt-native-packager concept of bashScriptExtraDefines to append an appropriate javaagent:
updated build.sbt:
import com.typesafe.sbt.SbtAspectj._
lazy val root = (project in file(".")).settings(
aspectjSettings,
bashScriptExtraDefines += scriptClasspath.value
.filter(_.contains("aspectjweaver"))
.headOption
.map("addJava -javaagent:${lib_dir}/" + _)
.getOrElse(""),
fork in run := true
)
You can add the following settings in your sbt config:
.settings(
retrieveManaged := true,
libraryDependencies += "org.aspectj" % "aspectjweaver" % aspectJWeaverV)
AspectJ weaver JAR will be copied to ./lib_managed/jars/org.aspectj/aspectjweaver/aspectjweaver-[aspectJWeaverV].jar in your project root.
I actually solved this by using the sbt-javaagent plugin to adding agents to the runtime
How can SBT builds be made reliable enough to use in a production environment?
Specifically, SBT normally builds without a problem, but every few weeks, the commons-imaging dependency is not found, halting the entire build.
In build.sbt:
libraryDependencies ++= Seq(
, "commons-io" % "commons-io" % "2.4"
, "org.apache.commons" % "commons-imaging" % "1.0-SNAPSHOT" withSources ()
)
resolvers in ThisBuild ++= Seq(
"Apache Development Snapshot Repository" at "https://repository.apache.org/content/repositories/snapshots/"
)
sbt.ResolveException: unresolved dependency: org.apache.commons#commons-imaging;1.0-SNAPSHOT: not found
This usually works fine. But recently started giving:
[warn] Unable to reparse org.apache.commons#commons-imaging;1.0-SNAPSHOT from Apache Development Snapshot Repository
(1) Why would it be so intermittent? Is it the Resolver URL that changes, or the Web site that serves the commons-imaging jar going down? (other maven resources are found without ever experiencing a hiccup.)
(2) What can be done to ensure that clean builds always succeed? (This is crucial for spinning up a new instance and expecting it to succeed.)
Edit: This doesn't answer the question, but I found a workaround for this particular issue in that deleting "withSources()" allows the build to succeed.
I am getting deprecation and feature warnings when compiling my SBT project definition (i.e. the files inside the project directory). SBT version is 0.13.0.
I do not get more info on these by setting scalacOptions := Seq("-feature", "-deprecation"), this only seems to work for project source files and not project definition files.
Anyone know how I can set deprecation and warning for the compiler when it compiles the project definition?
[info] Loading project definition from /home/xxx/website/project
[warn] there were 2 deprecation warning(s); re-run with -deprecation for details
[warn] there were 4 feature warning(s); re-run with -feature for details
[warn] two warnings found
Create project/build.sbt project definition file with the following content:
scalacOptions := Seq("-feature", "-deprecation")
Since any *.sbt file under project belongs to the meta (build) project, it sets up the Scala compiler for the build configuration not the environment for the project under build.
It was tested with a sample sbt multi-project:
[info] Compiling 1 Scala source to /Users/jacek/sandbox/so/multi-0.13.1/project/target/scala-2.10/sbt-0.13/classes...
[warn] /Users/jacek/sandbox/so/multi-0.13.1/project/Build.scala:4: method error in object Predef is deprecated: Use `sys.error(message)` instead
[warn] lazy val e = error("Launcher did not provide the Ivy home directory.")
[warn] ^
[warn] one warning found
...when it compiled the following project/Build.scala:
import sbt._
object Build extends Build {
lazy val e = error("Launcher did not provide the Ivy home directory.")
}
My build.sbt has the following content:
name := "hello-world"
version := "1.0"
scalaVersion := "2.10.3"
libraryDependencies += "net.sourceforge.htmlunit" %% "htmlunit" % "2.13"
When I perform update in sbt console it says:
[error] (*:update) sbt.ResolveException: unresolved dependency: net.sourceforge.htmlunit#htmlunit_2.10;2.13: not found
What should I do to make sbt find this library?
Just use a single % instead of double %% in the dependency.
libraryDependencies += "net.sourceforge.htmlunit" % "htmlunit" % "2.13"
%% is only required when the path of the jar contains Scala version which is not a case for the dependency. I figured it out consulting mvnrepository - http://mvnrepository.com/artifact/net.sourceforge.htmlunit/htmlunit/2.13. Just hover over the 'Download(JAR)' link and you can see the full path.
Note: By default sbt uses the standard Maven2 repository. In case you have dependent jars that cannot be found in the default repo, then you need to add custom resolvers like this
resolvers += "custom_repo" at "url"
For this particular example resolvers are not required since htmlunit is present in default repo.