New Maven images with prefetched local repo speeds up Maven build startup

[Tibor17]

When you run Maven with empty local repo, it looks like Maven sleeps but it downloads plugins in the background. Having new images e.g. 3.6.2-jdk-14-prefetched would speed up the start up of the build. Just RUN the command mvn clean install and let the Maven to download the plugins when you build the image. Then push the image to dockerhub. Thx

[Tibor17]

@softbrada Can you tell me why you disagree? We in ASF Maven spoke about prefetched local cache and we can see it as a big mprovement. I do not say that the current images should have the cache. I named the image 3.6.2-jdk-14-prefetched because it is a new one. All Dockerfile-s and images would stay as before.

[carlossg]

you can already do this yourself with https://github.com/carlossg/docker-maven#packaging-a-local-repository-with-the-image

[Tibor17]

@carlossg I know what you mean but in our case we are not a user. We develop the Maven itself in Apache. So we were thinking about deploying Maven docker images with pre installed plugins (not a customer's dependencies). This would speed up the start time of the container or Maven build process actually.

So there was one idea in ASF to build images by us. And second idea was to ask you to support us with new additional fat images. The fat images would differ against the current ones only that the plugins would be preinstalled in the cache so the users would not wait too long when his container starts up.

And since Carloss' images on Dockerhut are so famous and the result so good that we don't want to compete.

[carlossg]

we can post prebuild images but we would need to figure out what plugins to include and how to manage the combinations between base image and plugins

[Tibor17]

we can post prebuild images but we would need to figure out what plugins to include and how to manage the combinations between base image and plugins

Very good point. A separate image with plugins was what I had in my mind too but one of my colleage pointed out that Maven may change the set of versions of plugins between releases. It does not happen very often, e.g. next time it will be in the version 3.7.0 after long period.

to figure out what plugins to include

yes, so we were facing two options:

• the set of plugins per Maven release with certain versions defined by the Maven dist, or
• the range of versions of the plugins for the build lifecycle.

The answer also depends on e.g. the size of local cache. A simple experiment (often used command mvn clean install) on trivial project shows that the size of the local cache is only 12 MB and this way we speed up the build in 50 seconds.

I guess the size is not big but the ping pong between Maven and repository causes that the user has to wait. It is funny situation on conferences when the presenter starts a container and the audience is wating one minute because the console shows pretty nothing and the Maven downloads basic plugins in the background. ;-)

Regarding the concrete plugins, it should be whole spectrum related to the lifecycles and the plugins would be mostly these: clean, resources, compiler, surefire, jar, war, ear, ..., install, maybe the deploy and the site plugin as well.

@carlossg If you agree, I would open a public thread on the Maven maling list for developers and you, and our collagues who are involved in this activity would join us. I hope you will attend the discussion too.

[carlossg]

you can have one or multiple pom.xml that gets executed as a multi stage docker build then keeps the plugins. That's probably the easiest way to download the plugins without having to worry about versions