Hello Adam!
I'm just coming from configuring pretty much what yu're trying to
achieve, but on OpenShift (which uses Docker, but it comes with a higher
level of orchestration).
From what I understand, you're trying to achieve a 2-stage deploy of
your app, where you want to separate the "building" from the "running"
into two separate phases/containers.
If that's the case, I've come across this article that helped me
understand the 2-stage build "pattern":
https://codefresh.io/docker-tutorial/java_docker_pipeline/ the "Maven
Builder Docker image" paragraph.
I have tested a version for my app with docker and yes, there is a
problem with the lazy download if you're only using the pom.xml inside
the builder image.
Since you're binding the pom.xml (which is app specific, I'm guessing),
why not copy and build the entire app at the build stage for the docker
image? Not really an elegant solution here, but it works for incremental
builds when the pom doesn't change. If you're trying to achieve an
"universal" maven-builder-image with Docker, I guess external volume for
the repository would be the way, because the actual builder image is
volatile (ran with the --rm argument) so it doesn't store anything
except that which was created at build time.
As I mentioned, my final goal was getting it to work under OpenShift
which has an extra set of options to do that, so I haven't really tested
it further under Docker alone.
What OpenShift does, is integrate a tool/project that's called Source to
Image : https://github.com/openshift/source-to-image
If you're not bound by the tools you need to use (so Docker alone), I
guess it's worth looking into this. What this tool does is integrate
with the Docker image and injects data/runs parametrization specified in
a set of standard scripts: "save-artifacts" (which is of interest with
your current issue), "assemble" (where you specify the steps for the
build/deploy) and "run" (which defines how to start the running
instance/image after all was set).
Disclaimer: I'm not a certified/experienced Docker guy! Have thought
about giving my two cents around this issue, as I've came across it
quite recently too.
On 20.02.2018 13:22, Adam Sandor wrote:
Hi Herve,
Thank you very much for taking a look at this. Unfortunately running
"versions:display-plugin-updates" says all plugins have a version
specified. My pom file is practically empty - it's a tiny spring boot app (
https://github.com/adam-sandor/memoryhog/blob/master/pom.xml).
Any other ideas?
Here is the output of the version plugin, and here you can see the output
of "mvn package" after "mvn dependency:go-offline" has already ran:
https://gist.github.com/adam-sandor/9296560d8bdae3f77f6b1160c0635e55
[INFO]
[INFO] All plugins with a version specified are using the latest versions.
[INFO]
[INFO] All plugins have a version specified.
[INFO]
On Mon, Feb 19, 2018 at 5:46 PM Hervé BOUTEMY <herve.bout...@free.fr> wrote:
Le lundi 19 février 2018, 09:25:13 CET Adam Sandor a écrit :
Hello Maven people,
Can someone at least give me some feedback on why this one is not
getting any answers? Asked the question in a wrong way? Is it not
clear? Not interesting?
I suppose this is a mix that not many people are fluent with
I'll try to help.
I think supporting Docker-based builds is very important today. I'm
thinking of contributing code to solve this issue, but I first want to
confirm I didn't miss some solution that is already available.
Adam
On Sun, Feb 4, 2018 at 12:57 PM, Adam Sandor
<adam.san...@container-solutions.com> wrote:
I’m trying to figure out how to create a two-stage Docker build using
Maven
that would properly utilise Docker layer caching. Containing the whole
build in a Docker container without external dependencies on volume
mounts (for .m2 cache) has a lot of advantages.
The only missing piece of the puzzle I can’t figure out is how to force
Maven to download ALL dependencies just by using the pom file and not
executing any compilation. The idea behind is to:
1. copy the pom file into the image
2. use maven to download all dependencies
3. copy the sources to the image
4. use maven to build the final artifact
This way Docker will reuse the layer containing the dependencies if the
pom
file didn’t change. So dependency caching would be implemented in a
Docker-ish way that works anywhere the Docker daemon is present as
opposed
to relying on Maven being installed and artifacts getting stored in a
shared .m2/repository directory.
Now the problem - Maven’s lazy downloading of dependencies. Even if I
try
to execute “mvn dependency:go-offline” Maven still doesn’t download
plugins and other dependencies, which would only be required during the
packaging phase.
Maven Dependency Plugin is supposed to download plugins: that's surprising
you
don't get one plugin downloaded.
There is one classical cause I imagine: did you define a version for every
plugin used?
You should be able to have a diagnostic through "mvn
versions:display-plugin-
updates"
Regards,
Hervé
So the following Docker file doesn’t work as intended:
FROM maven AS build
WORKDIR /build
ADD pom.xml /build
RUN mvn dependency:go-offline
ADD src /build/src
RUN mvn -o package
FROM openjdk:8-jdk
WORKDIR /app
COPY --from=build /build/target/app.jar /app
CMD java -jar /app/app.jar
Maven will still start downloading more dependencies on line 6.
I found a workaround for this - execute “mvn package” with a single
fake
main class on line 4, but this is not a nice solution. Can anyone give
me
some option I’m missing or confirm that this is the way things are? In
that
case I can go ahead write a blog post showing my workaround to help
other
struggling with the same problem. Thank you!
Adam Sandor from Container Solutions
--
Ádám Sándor
Senior Engineer / Consultant
Container Solutions
0680126174
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
