When publishing our plugin we got this
[info] Done packaging.
[trace] Stack trace suppressed: run last *:publish for the full output.
[error] (*:publish) java.io.IOException: PUT operation to URL https://nexus.mycompany.com/repository/maven-snapshots/com/foo/foo-sbt-plugin_2.10_0.13/1.0.0-SNAPSHOT/foo-sbt-plugin-1.0.0-SNAPSHOT.pom failed with status code 400: Invalid path for a Maven 2 repository
We set up the plugin using
sbtPlugin := true
publishMavenStyle := true
This was fixed by setting the repository Layout Policy to permissive in the nexus admin.
http://nexus.mycompany.com/#admin/repository/repositories:maven-releases
http://nexus.mycompany.com/#admin/repository/repositories:maven-snapshots
Related
I am coding a Java project and I'm automating the build and the publishing to JFrog Artifactory using SBT.
Whenever it's time to publish to Artifactory I want to do it using the Ivy directory layout and obviously publish the Ivy XML file along with the jar. I managed to achieve this by using the following lines in the build.sbt file:
crossPaths := false
publishTo := Some("Artifactory Realm" at "http://<Artifactory IP>:<Artifactory Port>/artifactory/org.project.my")
credentials += Credentials(Path.userHome / ".ivy2" / ".credentials")
publishMavenStyle := false
However it only works when anonymous users are allowed to deploy into Artifactory. I realized that sbt is not really passing my credentials to Artifactory but, instead, logging in as anonymous.
My $HOME/.ivy2/.credentials file looks like this:
realm=Artifactory Realm
host=http://<Artifactory IP>:<Artifactory Port>/artifactory/org.project.my
user=<my user name>
password=<my user name>
However, if I change the Artifactory configuration in order to prevent anonymous users from deploying new Artifacts, when I run "sbt publish" I get the following output:
[error] Unable to find credentials for [Artifactory Realm # <Artifactory IP>].
java.io.IOException: Access to URL http://<Artifactory IP>:<Artifactory Port>/artifactory//org.project.my/org/project/my/project-my/1.0.0/project-my-1.0.0.jar was refused by the server: Unauthorized
The Artifactory request.log file then contains:
20160219011657|319|REQUEST|10.0.2.2|anonymous|PUT|/org.project.my/org/project/my/project-my/1.0.0/project-my-1.0.0.jar|HTTP/1.1|401|24978
I have also tried passing the credentials manually instead of using a file:
credentials += Credentials("Artifactory Realm", "localhost", "<USERNAME>", "<PASS>")
But I am getting the same result.
Any idea what I might be missing?
try:
host=<Artifactory IP>
old answer (doesn't work):
host=<Artifactory IP>:<Artifactory port>
I had a different problem: I had the wrong realm set on my .credentials file.
Looking at the error output from sbt, I was able to figure out that I should use:
realm=Artifactory Realm
Error shows the expected values for realm and host:
[error] Unable to find credentials for [Artifactory Realm # myhost].
I need to retrieve dependencies from a secured internal Nexus OSS repository.
I don't need to make any deploy at the moment, only get the dependencies, but I'm having no luck.
This is my build.sbt file:
credentials += Credentials("Sonatype Nexus Repository Manager", "repo.server.com", "admin", "admin123")
libraryDependencies += "group" % "artifact" % "1.0.0"
The realm is the one returned by Nexus.
This my ~/.sbt/repositories file:
[repositories]
local
releases: https://repo.server.com:8110/nexus/content/repositories/releases/
ivy-releases: https://repo.server.com:8110/nexus/content/groups/ivy-releases/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
custom-public: https://repo.server.com:8110/nexus/content/groups/custom-public
I have three repos:
custom-public is open for the anonymous user. I does not include the releases repo.
ivy-releases its a group with Typesafe ivy releases and SBT plugin releases. It is public too, and its separated from custom-public following the advice in this guide.
releases is restricted to some users.
This is my SBT_OPTS environment variable:
set SBT_OPTS=-Dsbt.override.build.repos=true -Xmx1024M -Xss20m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=128m -Dsbt.log.format=true -Djavax.net.ssl.trustStore=~/trust.jks -Djavax.net.ssl.trustStorePassword=passs
SBT finds the public repos without problem. But I could not make it download any dependency from the restricted repo. It gives the following error:
[warn] module not found: group#artifact;1.0.0
[warn] ==== local: tried
[warn] C:\Documents and Settings\gferrari\.ivy2\local\group\artifact\1.0.0\ivys\ivy.xml
[warn] ==== releases: tried
[warn] https://repo.server.com:8110/nexus/content/repositories/releases/group/artifact/1.0.0/artifact-1.0.0.pom
[warn] ==== ivy-releases: tried
[warn] https://repo.server.com:8110/nexus/content/groups/ivy-releases/group/artifact/1.0.0/ivys/ivy.xml
[warn] ==== custom-public: tried
[warn] https://repo.server.com:8110/nexus/content/groups/custom-public/group/artifact/1.0.0/artifact-1.0.0.pom
If I try the releases url https://repo.server.com:8110/nexus/content/repositories/releases/group/artifact/1.0.0/artifact-1.0.0.pom in the browser, with the admin user logged in, it shows the pom file correctly.
What options do I have to troubleshoot this problem?
It turned out to be an issue with the jsessionid request parameter in the production webserver (Oracle iPlanet).
These are the steps I've made to troubleshoot the problem:
I mirrored the server configuration in a local Nexus installation running on Tomcat, which worked OK.
Then I run the same command (compile) over both installations and compared the Nexus logs (with level DEBUG).
At some point on Tomcat, Nexus reported that no session was found and proceeded to search for user credentials in the http headers. At the same point on iPlanet, Nexus found a valid Session of the anonymous user, and never looked at the http headers.
This was the reason the user was forbidden to access the artifact. It was mistaken as the anonymous user.
Following this SO answer I've added a filter in the Nexus web.xml to remove any jsessionid parameter using the Tuckey rewrite filter.
After that change, the server stopped to create spurious sessions, and started to correctly locate the user credentials in the http headers.
There should be some iPlanet configuration parameter to change the behaviour regarding the jsessionid parameter. The above steps are just my current solution.
I'm doing an app with JHipster 1.4.0 using Eclipse.
In dev profile, no problem, but when i switched to prod profile, there's an error in build :
Description : Plugin execution not covered by lifecycle configuration: com.github.trecloux:yeoman-maven-plugin:0.2:build (execution: run-grunt, phase: generate-resources)
Resource : pom.xml
Path : /myapp
Location : line 444
Type : Maven Project Build Lifecycle Mapping Problem
I'm new to Eclipse and i didn't find a solution on forums. If someone can help...
Thanks !
I just had a same issue, and this was because I had another process using the same port number as Grunt (port 9001).
Can you check your Grunt error message? I had:
Running "connect:test" (connect) task
Fatal error: Port 9001 is already in use by another process.
When starting Typesafe Activator using activator ui, there are messages starting with Getting. What do sbt-rc-probe-0-13 and sbt-rc-ui-interface-0-13 do for activator?
➜ no-trace-deps activator ui
Checking for a newer version of Activator (current version 1.2.10)...
... our current version 1.2.10 looks like the latest.
Found previous process id: 36033
FOUND REPO = activator-local # file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository
Play server process ID is 39625
[info] play - Application started (Prod)
[info] play - Listening for HTTP on /127.0.0.1:8888
[info] a.e.s.Slf4jLogger - Slf4jLogger started
Getting com.typesafe.sbtrc sbt-rc-probe-0-13 1.0-c50ddab5e1332398049a2a649261e1ca24577479 ...
downloading file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository/com.typesafe.sbtrc/sbt-rc-probe-0-13/1.0-c50ddab5e1332398049a2a649261e1ca24577479/jars/sbt-rc-probe-0-13.jar ...
[SUCCESSFUL ] com.typesafe.sbtrc#sbt-rc-probe-0-13;1.0-c50ddab5e1332398049a2a649261e1ca24577479!sbt-rc-probe-0-13.jar (12ms)
:: retrieving :: org.scala-sbt#boot-app
confs: [default]
2 artifacts copied, 0 already retrieved (414kB/8ms)
Getting com.typesafe.sbtrc sbt-rc-ui-interface-0-13 1.0-c50ddab5e1332398049a2a649261e1ca24577479 ...
downloading file:/usr/local/Cellar/typesafe-activator/1.2.10/libexec/repository/com.typesafe.sbtrc/sbt-rc-ui-interface-0-13/1.0-c50ddab5e1332398049a2a649261e1ca24577479/jars/sbt-rc-ui-interface-0-13.jar ...
[SUCCESSFUL ] com.typesafe.sbtrc#sbt-rc-ui-interface-0-13;1.0-c50ddab5e1332398049a2a649261e1ca24577479!sbt-rc-ui-interface-0-13.jar (4ms)
:: retrieving :: org.scala-sbt#boot-app
confs: [default]
1 artifacts copied, 0 already retrieved (32kB/4ms)
[info] application - error getting name from sbt: sbt process never got in touch, so unable to handle request NameRequest(true)
[info] application - using file basename as app name: no-trace-deps
[INFO] [09/26/2014 19:41:14.587] [default-akka.actor.default-dispatcher-3] [akka://default/user/app-no-trace-deps-1/socket] Firing up web socket
These were part of the old sbt-remote-control API (the prototype for sbt server).
The "probe" is what sits inside sbt and communicates task results/commands to/from the activator process and the sbt server.
The 'ui-interface' is an API where plugins can directly send messages to activator from within sbt.
These will make a bit more sense with the new sbt-server pre-release where "ui-interface" is renamed "server-interface" (I think) and the Play plugin can directly communicate to clients (like IDEs/Activator).
I'm trying to install sbt on windows 7 but testing it, I get the following error:
java.nio.channels.OverlappingFileLockException
at sun.nio.ch.SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.SharedFileLockTable.add(Unknown Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.tryLock(Unknown Source)
at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:88)
at xsbt.boot.Locks$GlobalLock.withChannelRetries$1(Locks.scala:81)
at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:102)
at xsbt.boot.Using$.withResource(Using.scala:11)
at xsbt.boot.Using$.apply(Using.scala:10)
at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:62)
at xsbt.boot.Locks$GlobalLock.liftedTree1$1(Locks.scala:52)
at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:52)
at xsbt.boot.Locks$.apply0(Locks.scala:31)
at xsbt.boot.Locks$.apply(Locks.scala:28)
at xsbt.boot.Update.apply(Checks.java:100)
at xsbt.boot.Launch.update(Launch.scala:266)
at xsbt.boot.Launch.retrieve$1(Launch.scala:136)
at xsbt.boot.Launch$$anonfun$3.apply(Launch.scala:144)
at scala.Option.getOrElse(Option.scala:108)
at xsbt.boot.Launch$$anon$2.call(Launch.scala:129)
at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:98)
at xsbt.boot.Locks$GlobalLock.withChannelRetries$1(Locks.scala:81)
at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:102)
at xsbt.boot.Using$.withResource(Using.scala:11)
at xsbt.boot.Using$.apply(Using.scala:10)
at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:62)
at xsbt.boot.Locks$GlobalLock.liftedTree1$1(Locks.scala:52)
at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:52)
at xsbt.boot.Locks$.apply0(Locks.scala:31)
at xsbt.boot.Locks$.apply(Locks.scala:28)
at xsbt.boot.Launch.locked(Launch.scala:165)
at xsbt.boot.Launch.app(Launch.scala:82)
at xsbt.boot.Launch.app(Launch.scala:80)
at xsbt.boot.Launch$.run(Launch.scala:51)
at xsbt.boot.Launch$$anonfun$explicit$1.apply(Launch.scala:45)
at xsbt.boot.Launch$.launch(Launch.scala:60)
at xsbt.boot.Launch$.apply(Launch.scala:16)
at xsbt.boot.Boot$.runImpl(Boot.scala:31)
at xsbt.boot.Boot$.main(Boot.scala:20)
at xsbt.boot.Boot.main(Boot.scala)
at SbtJansiLaunch.main(SbtJansiLaunch.java:4)
Error during sbt execution: java.nio.channels.OverlappingFileLockException
which seems related to the fact that I do have access to my remote HOME drive according to this post:
https://groups.google.com/forum/#!topic/simple-build-tool/lJvOvZ5RUwE
I tried to follow what they suggest, but I have never found any sbt.boot.properties file. I have also tried to overwrite the boot and working dir via:
sbt -sbt-dir C:\my\new\home -sbt-boot C:\my\new\home
Would any of you have gone through all these problems and could have a step-by-step recipy to solve that ?
Ok so I had the same problem. The sbt.boot.properties file resides inside the sbt-launch.jar archive. Open it with an archive tool like winzip or 7zip and then look in the folder /sbt and you will see the sbt.boot.properties file.
The current version looks like this
[scala]
version: ${sbt.scala.version-auto}
[app]
org: ${sbt.organization-org.scala-sbt}
name: sbt
version: ${sbt.version-read(sbt.version)[0.13.6]}
class: ${sbt.main.class-sbt.xMain}
components: xsbti,extra
cross-versioned: ${sbt.cross.versioned-false}
resources: ${sbt.extraClasspath-}
[repositories]
local
typesafe-ivy-releases: https://repo.typesafe.com/typesafe/ivy-releases/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext], bootOnly
maven-central
[boot]
directory: ${sbt.boot.directory-${sbt.global.base-${user.home}/.sbt}/boot/}
[ivy]
ivy-home: ${sbt.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}
Make sure you add the property lock in the [boot] section or you will get another error. So eventually it should look like this:
[scala]
version: ${sbt.scala.version-auto}
[app]
org: ${sbt.organization-org.scala-sbt}
name: sbt
version: ${sbt.version-read(sbt.version)[0.13.6]}
class: ${sbt.main.class-sbt.xMain}
components: xsbti,extra
cross-versioned: ${sbt.cross.versioned-false}
resources: ${sbt.extraClasspath-}
[repositories]
local
typesafe-ivy-releases: https://repo.typesafe.com/typesafe/ivy-releases/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext], bootOnly
maven-central
[boot]
directory: ${sbt.boot.directory-${sbt.global.base-${user.home}/.sbt}/boot/}
lock: false
[ivy]
ivy-home: ${sbt.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}
Another point of attention is also what they said on that google group. Do not run two sbt processes at the same time, as this parameter might cause inconsistencies then.