Answers: <p>You are using docker wrongly in this case IMHO and I have a serious doubt that your <code>docker exec</code> command is targeting the correct container because, from what I see (and my very limited knowledge of sbt/scala), it should be dead by the time the jar is published. Let me explain.</p>
  
  <p><code>sbt publishLocal</code> is not a long living command. It will exit when the jar is published to the local <code>.ivy</code> store on disk. So when you launch a container from your image in foreground with <code>docker run --name mytestcontainer myproject:v1</code> (I added a name for easier debugging purpose on your side...), I am pretty sure you see all your above logs and that the command exits back to your shell.</p>
  
  <p>At this point, if you issue a <code>docker ps</code>, your <code>mytestcontainer</code> will not show up, unless with <code>docker ps -a</code>where it will be listed in the exited container. If you try to start it again (<code>docker start mytestcontainer</code>), it will exit as soon as the jar is re-compiled/published. So there is no way to target an <code>exec</code> on this container since it is not running. The only way to have a shell in a running container out of this image is to override the start command in <code>docker run</code> but this will bypass your jar publication.</p>
  
  <p>Now, what you first want is to publish the jar as part of the image, not to compile/publish it everytime you start a container out of the image.</p>
  
  <pre><code>FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8
  MAINTAINER Sara Waheed &lt;sarawaheed3191@gmail.com&gt;
  
  WORKDIR /myproject
  ADD . /myproject
  
  RUN sbt publishLocal
  </code></pre>
  
  <p>In this case, the jar will be published during the build</p>
  
  <pre><code>docker build -t myproject:v1
  </code></pre>
  
  <p>You can then run a container out of your image dropping to jshell as intended by the base image you are using:</p>
  
  <pre><code>docker run -it --rm --name testcontainer myproject:v1
  May 12, 2019 8:31:33 AM java.util.prefs.FileSystemPreferences$1 run
  INFO: Created user preferences directory.
  |  Welcome to JShell -- Version 11.0.2
  |  For an introduction type: /help intro
  
  jshell&gt;
  </code></pre>
  
  <p>Or if you want a more classic bash shell, you can override the start command:</p>
  
  <pre><code>docker run -it --rm --name testcontainer myproject:v1 /bin/bash
  </code></pre>
  
  <p>To go further, if your intent is to deliver your application in a ready to use image, you should have a look at <a href="https://docs.docker.com/develop/develop-images/multistage-build/" rel="nofollow noreferrer">Docker multistage builds</a>. The idea is to build your jar in an image containing all the needed build tools and to copy the produced artifacts to an other image intended only for run that you will finally distribute. Here is the basic idea from your example. Image/command used are solely for illustration purpose and the process is highly perfectible (e.g. harcoded version....):</p>
  
  <pre><code>FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8 as build
  WORKDIR /myproject
  ADD . /myproject
  RUN sbt publishLocal
  
  FROM openjdk:8-alpine
  WORKDIR /myproject
  COPY --from=build /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar .
  CMD['java', '-jar', 'myproject.jar']
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-12T09:04:24.540Z
Answers: 2019-05-12T09:04:24.540Z
Answers: Zeitounator
Answers: <p>Not knowing anything about the java appication, but just going on what you can do with docker: The workdir for the parent image is /root. You can try to omit the WORKDIR statement. The build script might be working in the current directory, which would not be /root, but /workdir. Or you can add WORKDIR /root again before CMD. </p>
  
  <p>Also don't forget some basic checks, eg. </p>
  
  <pre><code>df -h 
  </code></pre>
  
  <p>to check if your server has enough free space (granted, it would have given an error message.) Also remove old containers: </p>
  
  <pre><code>docker ps -a 
  docker rm containername
  docker images
  docker rmi imagename
  </code></pre>
  
  <p>If you add the WORKDIR root at the end, and the jar is created at</p>
  
  <pre><code> /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars/root_2.12.jar 
  </code></pre>
  
  <p>instead of, say:</p>
  
  <pre><code>/root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar
  </code></pre>
  
  <p>You can try to find the scripts that generate that path with grep:</p>
  
  <pre><code>egrep -r '(jars|root|default)' * 
  </code></pre>
  
  <p>This will recursively list all the files where those terms appear. You can scan them for clues so as to what configuration files or environment variables to use. Also check the configuration section of the documentation for the jar generating application. (It's not software I am familiar with.) If you find that there is an environment variable that informs the location, lets say for example PROJECT, then you can include it in the Dockerfile:</p>
  
  <pre><code>ENV PROJECT myproject.test.com
  </code></pre>
  
  <p>Or if you want to dynamically pass it to the container when you run it:</p>
  
  <pre><code>docker run -E PROJECT=myproject.test.com myproject:v1
  </code></pre>
  
  <p>More likely however, is that it is inside some sort of configuration file that you need to copy to the container. Because "docker build" copies all the files in the current directory, you can just create the file in the current directory. Or if you need to manually put it somewhere else:</p>
  
  <pre><code>PUT configfile /some/path
  </code></pre>
  
  <p>Or</p>
  
  <pre><code>RUN mv configfile /some/path
  </code></pre>
  
  <p>Or you can create it dynamically inside the container. If it's just one line that needs to be in a file in the container:</p>
  
  <pre><code>RUN bash -c "echo project: myproject.test.com &gt; /some/path/configfile"
  </code></pre>
  
  <p>As a plan B you can always just create a softlink inside the container, if it will solve your problem:</p>
  
  <pre><code>mkdir -p /root/.ivy2/local/com.test/myproject/1.0.1
  ln -s /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars /root/.ivy2/local/com.test/myproject/1.0.1/
  </code></pre>
  
  <p>You can also add this as a RUN command before the CMD in the Dockerfile:</p>
  
  <pre><code>RUN mkdir -p /root/.ivy2/local/com.test/myproject/1.0.1 &amp;&amp; /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars /root/.ivy2/local/com.test/myproject/1.0.1/
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-11T08:50:26.277Z
Answers: first of all thank you so much for your response i have tried your solution i removed workdir and tested and added workdir /root but it did not helped also the jar renamed to published root_2.12 to /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars/root_2.12.jar
   instead of /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar
Answers: sarah w
Answers: CC BY-SA 4.0
Answers: 2019-05-13T06:31:11.263Z
Answers: If you can't find the right place to change the name from default to com.test you can always just go and create a softlink in /root/.ivy2/local, instructions added.
Answers: Dagelf
Answers: CC BY-SA 4.0
Answers: 2019-05-10T15:13:48.107Z
Answers: 2019-05-13T06:48:03.743Z
Answers: 2019-05-13T06:48:03.743Z
Answers: Dagelf
Body: <p>I have an sbt project and i am creating its Jar using the  <code>sbt publishLocal</code> command and i want a docker image for that i am doing something like this </p>
  
  <pre><code>FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8
  
  MAINTAINER Sara Waheed &lt;sarawaheed3191@gmail.com&gt;
  
  WORKDIR /myproject
  
  ADD . /myproject
  
  # Define default command.
  CMD ["sbt", "publishLocal"]
  </code></pre>
  
  <p>and i am building it <code>docker build -t myproject:v1</code> and run it <code>docker run myproject:v1</code>
  i have seen in the logs </p>
  
  <pre><code>[info] Main Java API documentation successful.
  [info] Packaging /stripe-payment-account/target/myproject-1.0.1-javadoc.jar ...
  [info] Done packaging.
  [info] :: delivering :: com.test#myproject;1.0.1 :: 1.0.1 :: release :: Tue May 07 10:26:13 UTC 2019
  [info]  delivering ivy file to /stripe-payment-account/target/ivy-1.0.1.xml
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/poms/myproject.pom
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/srcs/myproject-sources.jar
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/docs/myproject-javadoc.jar
  [info]  published ivy to /root/.ivy2/local/com.test/myproject/1.0.1/ivys/ivy.xml
  [success] Total time: 77 s, completed May 7, 2019, 10:26:13 AM
  </code></pre>
  
  <p>and when i try to look the file contents of this container via </p>
  
  <pre><code>docker exec -t -i containerid /bin/bash
  </code></pre>
  
  <p>and look into </p>
  
  <pre><code>cd ///root/.ivy2 
  </code></pre>
  
  <p>and ls -a only shows </p>
  
  <pre><code>.  ..  .sbt.ivy.lock  cache
  </code></pre>
  
  <p>the local folder is missing here but when i run the container it shows that it created the jar in <code>/root/.ivy2/local/com.test/myproject/1.0.1/docs/myproject-javadoc.jar</code></p>
  
  <p>why its not showing the local folder in <code>.ivy2</code> folder what i am doing wrong here?</p>
  
Tags: <docker><dockerfile>
Title: jar file is not displaying in docker container
UserDisplayName: sarah w
ThreadText: # jar file is not displaying in docker container
  
  (Asked by: username_0 on 2019-05-09)
  
  I have an sbt project and i am creating its Jar using the `sbt publishLocal` command and i want a docker image for that i am doing something like this
  
  ```
  FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8
  
  MAINTAINER Sara Waheed <sarawaheed3191@gmail.com>
  
  WORKDIR /myproject
  
  ADD . /myproject
  
  # Define default command.
  CMD ["sbt", "publishLocal"]
  
  ```
  
  and i am building it `docker build -t myproject:v1` and run it `docker run myproject:v1`
  i have seen in the logs
  
  ```
  [info] Main Java API documentation successful.
  [info] Packaging /stripe-payment-account/target/myproject-1.0.1-javadoc.jar ...
  [info] Done packaging.
  [info] :: delivering :: com.test#myproject;1.0.1 :: 1.0.1 :: release :: Tue May 07 10:26:13 UTC 2019
  [info]  delivering ivy file to /stripe-payment-account/target/ivy-1.0.1.xml
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/poms/myproject.pom
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/srcs/myproject-sources.jar
  [info]  published myproject to /root/.ivy2/local/com.test/myproject/1.0.1/docs/myproject-javadoc.jar
  [info]  published ivy to /root/.ivy2/local/com.test/myproject/1.0.1/ivys/ivy.xml
  [success] Total time: 77 s, completed May 7, 2019, 10:26:13 AM
  
  ```
  
  and when i try to look the file contents of this container via
  
  ```
  docker exec -t -i containerid /bin/bash
  
  ```
  
  and look into
  
  ```
  cd ///root/.ivy2 
  
  ```
  
  and ls -a only shows
  
  ```
  .  ..  .sbt.ivy.lock  cache
  
  ```
  
  the local folder is missing here but when i run the container it shows that it created the jar in `/root/.ivy2/local/com.test/myproject/1.0.1/docs/myproject-javadoc.jar`
  
  why its not showing the local folder in `.ivy2` folder what i am doing wrong here?
  
  **Tags:** docker, dockerfile
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-05-12. Score: 1
  
  You are using docker wrongly in this case IMHO and I have a serious doubt that your `docker exec` command is targeting the correct container because, from what I see (and my very limited knowledge of sbt/scala), it should be dead by the time the jar is published. Let me explain.
  
  `sbt publishLocal` is not a long living command. It will exit when the jar is published to the local `.ivy` store on disk. So when you launch a container from your image in foreground with `docker run --name mytestcontainer myproject:v1` (I added a name for easier debugging purpose on your side...), I am pretty sure you see all your above logs and that the command exits back to your shell.
  
  At this point, if you issue a `docker ps`, your `mytestcontainer` will not show up, unless with `docker ps -a`where it will be listed in the exited container. If you try to start it again (`docker start mytestcontainer`), it will exit as soon as the jar is re-compiled/published. So there is no way to target an `exec` on this container since it is not running. The only way to have a shell in a running container out of this image is to override the start command in `docker run` but this will bypass your jar publication.
  
  Now, what you first want is to publish the jar as part of the image, not to compile/publish it everytime you start a container out of the image.
  
  ```
  FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8
  MAINTAINER Sara Waheed <sarawaheed3191@gmail.com>
  
  WORKDIR /myproject
  ADD . /myproject
  
  RUN sbt publishLocal
  
  ```
  
  In this case, the jar will be published during the build
  
  ```
  docker build -t myproject:v1
  
  ```
  
  You can then run a container out of your image dropping to jshell as intended by the base image you are using:
  
  ```
  docker run -it --rm --name testcontainer myproject:v1
  May 12, 2019 8:31:33 AM java.util.prefs.FileSystemPreferences$1 run
  INFO: Created user preferences directory.
  |  Welcome to JShell -- Version 11.0.2
  |  For an introduction type: /help intro
  
  jshell>
  
  ```
  
  Or if you want a more classic bash shell, you can override the start command:
  
  ```
  docker run -it --rm --name testcontainer myproject:v1 /bin/bash
  
  ```
  
  To go further, if your intent is to deliver your application in a ready to use image, you should have a look at [Docker multistage builds](https://docs.docker.com/develop/develop-images/multistage-build/). The idea is to build your jar in an image containing all the needed build tools and to copy the produced artifacts to an other image intended only for run that you will finally distribute. Here is the basic idea from your example. Image/command used are solely for illustration purpose and the process is highly perfectible (e.g. harcoded version....):
  
  ```
  FROM hseeberger/scala-sbt:11.0.2_2.12.8_1.2.8 as build
  WORKDIR /myproject
  ADD . /myproject
  RUN sbt publishLocal
  
  FROM openjdk:8-alpine
  WORKDIR /myproject
  COPY --from=build /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar .
  CMD['java', '-jar', 'myproject.jar']
  
  ```
  
  
  ---
  
  ### Answer by username_2 on 2019-05-10. Score: 0
  
  Not knowing anything about the java appication, but just going on what you can do with docker: The workdir for the parent image is /root. You can try to omit the WORKDIR statement. The build script might be working in the current directory, which would not be /root, but /workdir. Or you can add WORKDIR /root again before CMD.
  
  Also don't forget some basic checks, eg.
  
  ```
  df -h 
  
  ```
  
  to check if your server has enough free space (granted, it would have given an error message.) Also remove old containers:
  
  ```
  docker ps -a 
  docker rm containername
  docker images
  docker rmi imagename
  
  ```
  
  If you add the WORKDIR root at the end, and the jar is created at
  
  ```
   /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars/root_2.12.jar 
  
  ```
  
  instead of, say:
  
  ```
  /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar
  
  ```
  
  You can try to find the scripts that generate that path with grep:
  
  ```
  egrep -r '(jars|root|default)' * 
  
  ```
  
  This will recursively list all the files where those terms appear. You can scan them for clues so as to what configuration files or environment variables to use. Also check the configuration section of the documentation for the jar generating application. (It's not software I am familiar with.) If you find that there is an environment variable that informs the location, lets say for example PROJECT, then you can include it in the Dockerfile:
  
  ```
  ENV PROJECT myproject.test.com
  
  ```
  
  Or if you want to dynamically pass it to the container when you run it:
  
  ```
  docker run -E PROJECT=myproject.test.com myproject:v1
  
  ```
  
  More likely however, is that it is inside some sort of configuration file that you need to copy to the container. Because "docker build" copies all the files in the current directory, you can just create the file in the current directory. Or if you need to manually put it somewhere else:
  
  ```
  PUT configfile /some/path
  
  ```
  
  Or
  
  ```
  RUN mv configfile /some/path
  
  ```
  
  Or you can create it dynamically inside the container. If it's just one line that needs to be in a file in the container:
  
  ```
  RUN bash -c "echo project: myproject.test.com > /some/path/configfile"
  
  ```
  
  As a plan B you can always just create a softlink inside the container, if it will solve your problem:
  
  ```
  mkdir -p /root/.ivy2/local/com.test/myproject/1.0.1
  ln -s /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars /root/.ivy2/local/com.test/myproject/1.0.1/
  
  ```
  
  You can also add this as a RUN command before the CMD in the Dockerfile:
  
  ```
  RUN mkdir -p /root/.ivy2/local/com.test/myproject/1.0.1 && /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars /root/.ivy2/local/com.test/myproject/1.0.1/
  
  ```
  
  > **Comments:**
  > **username_0**: first of all thank you so much for your response i have tried your solution i removed workdir and tested and added workdir /root but it did not helped also the jar renamed to published root_2.12 to /root/.ivy2/local/default/root_2.12/0.1.0-SNAPSHOT/jars/root_2.12.jar  instead of /root/.ivy2/local/com.test/myproject/1.0.1/jars/myproject.jar  
  > **username_2**: If you can't find the right place to change the name from default to com.test you can always just go and create a softlink in /root/.ivy2/local, instructions added.  
  
  ---
  
  