Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sbt.ivy.home and ivy.home properties both required #1894

Open
nkijak opened this issue Mar 2, 2015 · 9 comments
Open

sbt.ivy.home and ivy.home properties both required #1894

nkijak opened this issue Mar 2, 2015 · 9 comments
Labels

Comments

@nkijak
Copy link

nkijak commented Mar 2, 2015

Steps

  • Create a project for developing a plugin using the scripted plugin.
  • Run sbt scripted with sbt.ivy.home pointing to custom location that is not ~/.ivy2

Problem

  • When the tests run they pull dependencies from a location not specified by sbt.ivy.home, failing tests because they are unable to find the jars published during the publishLocal step

Expectations

  • The publishLocal task will place the plugin jar in the location specified by sbt.ivy.home
  • The scripted tasks will run and dependencies will be pulled from sbt.ivy.home
@eed3si9n eed3si9n added the Bug label Mar 2, 2015
@eed3si9n
Copy link
Member

eed3si9n commented Mar 2, 2015

Thanks for the report.

@eed3si9n
Copy link
Member

eed3si9n commented Mar 2, 2015

I'm thinking this can be fixed by forwarding the flag in the following line:

I wonder if anyone else might be relying on older semantics.

@jsuereth
Copy link
Member

jsuereth commented Mar 3, 2015

@eed3si9n dont' let the scripted bit fool you. The core issue here is that we need to set BOTH flags in sbt, because of inconsistent usage.

See: https://github.com/sbt/sbt/blob/0.13/ivy/src/main/scala/sbt/Resolver.scala#L359 as an example of somethign which should be "sbt.ivy.home" for consistency...

@eed3si9n
Copy link
Member

eed3si9n commented Mar 3, 2015

Maybe ivy.home is trying to be consistent with Ivy? I would vote for respecting both with sbt.ivy.home having higher precedence.

@eed3si9n eed3si9n added the area/library_management library management label Jun 25, 2015
@olafurpg
Copy link
Member

olafurpg commented Dec 12, 2016

Any update on this? I am experiencing the same issue as @nkijak. It appears that setting ivy.home and sbt.ivy.home in scriptedLaunchOpts does not help.

I've tried the following:

  • ivy-home set to /drone/.ivy2/ via sbt.boot
  • ivy.home and sbt.ivy.home set to /drone/.ivy2/ via scriptedLaunchOpts

My logs still show:

[info] 	published sbt-scalafix to /drone/.ivy2/local/ch.epfl.scala/sbt-scalafix/scala_2.10/sbt_0.13/0.2.0-RC2
....
[info] [warn] ==== local: tried
[info] [warn]   /root/.ivy2/local/ch.epfl.scala/sbt-scalafix/scala_2.10/sbt_0.13/0.2.0-RC2/ivys/ivy.xml

It works if I don't customize ivy.home, so my current plan is to re-arrange my ci to work that way.

@levinson
Copy link

This is a very confusing issue -- at the very least it should be documented better.

@a1kemist
Copy link

As @olafurpg points out, this makes it very difficult to run scripted tests in CI where you need to point to a custom ivy.home. Is there any workaround that someone has found?

This is what I tried to do for my situation:

export SBT_OPTS="-Dsbt.global.base=$CI_PROJECT_DIR/sbt-cache/.sbtboot -Dsbt.boot.directory=$CI_PROJECT_DIR/sbt-cache/.boot -Dsbt.ivy.home=$CI_PROJECT_DIR/.ivy"

Where CI_PROJECT_DIR is an env variable set by ci.
Then in scripted.sbt I added the following (because apparently SBT_OPTS aren't respected by the scripted task):

scriptedLaunchOpts := { scriptedLaunchOpts.value ++
    Seq("-Xmx1024M", "-Dplugin.version=" + version.value) ++
    // append SBT_OPTS so scripted launches with the correct cache dirs
    sys.env.get("SBT_OPTS").map(x => x.split(" ").toSeq).getOrElse(Nil)
}
scriptedBufferLog := false

This worked for most of the plugin projects I have been working on, but recently started failing again during a refactor.

After some investigation into that project, I found that the particular issue was due to scoping issues. Inspecting the value of scriptedLaunchOpts for the actual plugin project, revealed that it was missing my passthrough for SBT_OPTS. Adding those settings to my project specific settings made everything resolve properly after that.

I hope this helps someone else running into a similar issue with a custom sbt.ivy.home and running scripted tests for sbt plugins.

@eed3si9n
Copy link
Member

@kterusaki
Copy link

any update on this? As @a1kemist has pointed out, this the scripted plugin useless if we can't run it in CICD where we need to point to a custom sbt.ivy.home.

I have the following as my scriptedLaunchOptions:

scriptedLaunchOpts := {
    scriptedLaunchOpts.value ++
      Seq("-Xmx1024M", "-Dplugin.version=" + version.value, "-Dsbt.ivy.home=" + sys.props.get("sbt.ivy.home"))
  }

And I'm passing the sbt.ivy.home system property to sbt like so:

sbt -Dsbt.ivy.home=$HOME/.ivy-custom/ scripted

The error output is:

....
	Note: Unresolved dependencies path:
[info] [error] sbt.librarymanagement.ResolveException: Error downloading my.org:my-project;sbtVersion=1.0;scalaVersion=2.12:5.0-SNAPSHOT
[info] [error]   Not found
[info] [error]   Not found
[info] [error]   not found: /private/var/folders/4x/8xntqh9d3310fgv5s6ncn1980000gp/T/sbt_5918511/Some/Users/me/.ivy-custom/local/my.org/my-project/scala_2.12/sbt_1.0/5.0-SNAPSHOT/ivys/ivy.xml

The sbt.ivy.home system property is treated as a relative URL to the tmp directory used to scope the sbt plugin test. I'm not sure what the right fix is here. If everything needs to be scoped by the /private/var/... directory then maybe the scripted plugin should copy the local snapshot to this folder?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants