<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>

CC BY-SA 4.0
2019-05-12T09:04:24.540Z
2019-05-12T09:04:24.540Z
Zeitounator
<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>

CC BY-SA 4.0
2019-05-11T08:50:26.277Z
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
sarah w
CC BY-SA 4.0
2019-05-13T06:31:11.263Z
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.
Dagelf
CC BY-SA 4.0
2019-05-10T15:13:48.107Z
2019-05-13T06:48:03.743Z
2019-05-13T06:48:03.743Z
Dagelf
<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>

<docker><dockerfile>
jar file is not displaying in docker container
sarah w
# 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 

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 -awhere 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 

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. 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.  

---

