I don't want your dependencies of course because it is user specific issue. I only want to trigger "mvn clean install" or deploy and this will fetch the plugins, not the dependencies from a dummy empty pom. (don't mean user's pom). Finally, the user will have plugins in the image which come from the definition of the bindings for particular Maven dist. In 3.7.0 we will have new plugins in the bindings and so the dummy POM will not necessarily specify any. That's my point. I think it is very simple but the problem is if our group would deploy Docker images with default plugins in the cache or Carloss will do it.
On Wed, Oct 30, 2019 at 10:28 AM Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Wed 30 Oct 2019 at 08:21, Tibor Digana <tibordig...@apache.org> wrote: > > > It's the situation when you have maven plugins in repo and it means that > > all custom plugins/deps can be still downloaded as before. > > Nothing exists like this in the world and we are talking about the > > approaches. > > > > Cough cough cough > > > https://github.com/stephenc/docker-git-java8-maven-vim/blob/168b9968deae418ca3fd63c63038e896255c6fe8/Dockerfile#L50 > > There are issues, but it does shave a bit of time... though we end up > adding our common dependencies into the seed pom so that it is an effective > speed up > > > > > > I added Karl, Herve and Stephen in CC because we talked about this issue > > in ASF CON and Twitter. > > > > On Wed, Oct 30, 2019 at 6:36 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> Hi Tibor, > >> > >> It has two issues: > >> > >> 1. It will not be the right plugin versions in 90% of the cases (except > >> demo ;)) > >> 2. It will miss all custom plugins > >> > >> Now question is: what happens if you mount your local repo when running > >> docker? It works as expected. Means we could use a custom entrypoint > >> printing a warning banner if it is not done probably instead of > incrasing > >> the image size without being sure to reach the original goal. > >> > >> Wdyt? > >> > >> Romain > >> > >> Le mer. 30 oct. 2019 à 02:03, Tibor Digana <tibordig...@apache.org> a > >> écrit : > >> > >> > If you use Docker images with Maven with no mapping of cache to the > >> > volumes, you may notice that Maven downloads the plugins for the build > >> > lifecycle. > >> > > >> > This slows down the build because a lot of artifacts and plugins are > >> > initially downloaded. > >> > This takes 50 seconds which might be even longer than the productive > >> build > >> > itself (compiler, package, ...). > >> > > >> > We discussed this topic with Herve and Karl at the Apache CON 2019 the > >> last > >> > time. > >> > > >> > Sometime the presentations were funny because the audience had to > wait a > >> > minute while the console was black where the Maven was downloading the > >> > plugins in the background. > >> > Nobody was sure what happened that time, whether the console hanged or > >> the > >> > Cloud server hanged, or another issue happened with the network. > >> > > >> > I made a test and triggered the default lifecycle on Maven and I > >> realized > >> > that the cache was really very little, cca 12 MB. > >> > So this little cache in the container would save 50 seconds which is > the > >> > improvement we are discussing. > >> > > >> > From the use point of view, the user would use a new base image ` > >> > 3.6.2-jdk-14-prefetched` which is my idea. > >> > > >> > There are multiple technical solutions (range of plugins, extra pom, > >> > internal Maven plugin versions, etc). > >> > > >> > We understood that the best idea would be to have the image with the > >> cache > >> > in new Docker images produced by Carloss Sanchez. > >> > > >> > We are discussing this topic in [1] but we do not have a consensus on > >> who > >> > will develop the Docker scripts and how. > >> > > >> > We can continue here and we can propose a solution. > >> > > >> > [1] https://github.com/carlossg/docker-maven/issues/130 > >> > > >> > > >> > Cheers > >> > Tibor17 > >> > > >> > > -- > Sent from my phone >
