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

Problem using mvn at building time #32

Closed
doublebyte1 opened this issue Jul 6, 2017 · 6 comments
Closed

Problem using mvn at building time #32

doublebyte1 opened this issue Jul 6, 2017 · 6 comments

Comments

@doublebyte1
Copy link

I have the following use case:
1 - In the Dockerfile I build a mvn project and generate some jars
2 - then I go and build another project which uses the previous jars as dependencies

with the /root/.m2 volume, I find that the dependency jars (build on step 1), are gone, so I cannot successfully build the second project. This is maybe because the Dockerfile has layers, and the repository is not persisted in the second layer?

I already tried the approach that you advise in the README (using the settings.xml, as persisted repository), but I think this approach is designed to persist the repositories after the build of the Dockerfile , on runtime. I can see this image is designed to use maven on runtime, but what would be the correct way to use it also during building time?

@carlossg
Copy link
Owner

carlossg commented Jul 6, 2017

Nothing in /root/.m2 is persisted in the image, you would need to put the jars somewhere else

@doublebyte1
Copy link
Author

doublebyte1 commented Jul 6, 2017

Thanks for the quick reply. Based on what you said, this is what worked for me (maybe it can help others):

As the repository defined on settings.xml is only available on runtime, I have set it explicitly during my builds. Building the first project:

RUN mvn install -DskipTests -Drelax -gs /usr/share/maven/ref/settings-docker.xml

This has left the jars on /usr/share/maven/ref/repository, according to what is defined in settings.xml. Then I built the second project with the same flag:

RUN mvn install -DskipTests -Drelax -gs /usr/share/maven/ref/settings-docker.xml

And it found the dependencies on /usr/share/maven/ref/repository

@MrSleazy
Copy link

MrSleazy commented Jul 6, 2017

Hi @doublebyte1, @carlossg. Thanks for both of your answers.

I am actually having a similar issue. How did you customize the contents of setting-docker.xml inside of your image?

I currently need to set up a proxy for maven so I am trying to set up the build on a CI with the following image (https://github.com/alirizasaral/Maven-with-Proxy). This works fine, but I have the issue that maven downloads all the dependencies from scratch without caching them inside the repository every time I run a build on the CI.

Should I not be using an image based on alpine to get the maven repository to work correctly, or am I missing something more fundamental?

@cedricwalter
Copy link

@KevinSilvaQuintana

Add in your Dockerfile
COPY settings-docker.xml /usr/share/maven/ref/
in your docker directory, create a new file settings-docker.xml with content

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  | xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
  | https://maven.apache.org/xsd/settings-1.0.0.xsd">
  | <localRepository>/usr/share/maven/ref/repository</localRepository>
  | </settings>

use in all mvn command
RUN mvn install -DskipTests -Drelax -gs /usr/share/maven/ref/settings-docker.xml

run again a build with no-cache to avoid to reuse some step that were not creating dependency jar in new repository folder
sudo docker build --no-cache <yourdockerdirectory>

@MrSleazy
Copy link

Hi @cedricwalter ,

I actually ended up finding a solution which I have outlined in this post:
https://stackoverflow.com/questions/33430487/how-to-use-gitlab-ci-to-build-a-java-maven-project

However, between that and your solution, I am not sure which is more 'clean'. Your approach is very simple and straight forward. However, I think that being able to centralize everything in the CI build file will allow for a more generic re-use for future projects. I'll give it a try though. 👍

carlossg added a commit that referenced this issue Nov 10, 2017
It's a source of confusion for most users

Fixes #35 #32 #24 #11
@carlossg
Copy link
Owner

.m2 is no longer a volume

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

No branches or pull requests

4 participants