Re: [VOTE] Release Apache Maven Source Plugin version 3.2.0

[Romain Manni-Bucau]

+1 (non binding)

Le jeu. 31 oct. 2019 à 05:05, Olivier Lamy  a écrit :

> +1
>
> On Wed, 30 Oct 2019 at 7:44 am, Hervé BOUTEMY 
> wrote:
>
> > Hi,
> >
> > We solved 2 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924&=12345522=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1532/
> >
> >
> https://repository.apache.org/content/repositories/maven-1532/org/apache/maven/plugins/maven-source-plugin/3.2.0/maven-source-plugin-3.2.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-source-plugin-3.2.0-source-release.zip sha512:
> >
> 2321599d28affd25b2821a14182383a1a3a31bb33344fae395805d3173e9cdcfd2b1c09608e73a160f054f9086ad56f2b11f4fe56117fddb34356d1b8e935780
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [VOTE] Release Apache Maven Source Plugin version 3.2.0

[Olivier Lamy]

+1

On Wed, 30 Oct 2019 at 7:44 am, Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924&=12345522=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1532/
>
> https://repository.apache.org/content/repositories/maven-1532/org/apache/maven/plugins/maven-source-plugin/3.2.0/maven-source-plugin-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-source-plugin-3.2.0-source-release.zip sha512:
> 2321599d28affd25b2821a14182383a1a3a31bb33344fae395805d3173e9cdcfd2b1c09608e73a160f054f9086ad56f2b11f4fe56117fddb34356d1b8e935780
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Docker image with initialized local cache saves 50 seconds in startup

[Romain Manni-Bucau]

What is the usage of this first group outside demos (it is trivial to build
a dedicated image for demos so i drop it from any asf work for now)?

Le mer. 30 oct. 2019 à 23:18, Tibor Digana  a
écrit :

> Romain, of course we know this but there are two groups of users.
> First those who use the Maven in docker without CI.
> And second of those who integrate the docker container with the CI and they
> use the volumes.
>
> The first group of people may freely use the image we are discussing here
> because this makes the default build lifecycle faster for them.
> For us it means that we will not be seens as "slow Maven", you know what i
> mean.
>
> The second group already use the maven images from Carloss.
>
> On Wed, Oct 30, 2019 at 11:12 PM Romain Manni-Bucau  >
> wrote:
>
> > Ci servers have all cache so it is useless to make the docker pull slow
> > with useless versions to then download or not plugins IMHO.
> >
> > Le mer. 30 oct. 2019 à 22:47, Hervé Boutemy  a
> écrit
> > :
> >
> > > Le mercredi 30 octobre 2019 14:55:46 CET, vous avez écrit :
> > > > Agree we should publish with an asf account and make it part of the
> > > release
> > > > process.
> > > > That said I still fail to see how you can add a relevant cache. Maybe
> > > take
> > > > the time to review plugin version in a few asf projects (let say
> > > > maven-surefire, geronimo-openapi and spark) and check out if it works
> > to
> > > > cache anything.
> > > if we choose one precise version of each plugin, we will never get the
> > > version
> > > used by a project: IMHO, we need to choose a range for each plugin
> > > https://maven.apache.org/plugins/
> > > Something like dependency:resolve-plugins should be able to do the job.
> > >
> > > With a range per plugin, I'd love to see the size of the initial local
> > > repository
> > > At least, using such an image would require minimal efforts from users,
> > > particularly on CI servers
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau>
> > > > | LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 30 oct. 2019 à 14:31, Tibor Digana 
> a
> > > >
> > > > écrit :
> > > > > Stephen, yeah something like you do in your scrip but it must not
> be
> > a
> > > > > personal owner. Even Carloss is person who makes this deployment to
> > > > > DockerHub but his images are used by the entire world and we should
> > > decide
> > > > > whether we would agree with him to have such images under his
> > > > > responsibility or our responsibility as the Apache group. Then the
> > > script
> > > > > would be official and we can cut the release of Maven and the
> Docker
> > > image
> > > > > will be ready for the downloads together with the Maven
> distribution.
> > > So
> > > > > the users will always know that it is consistent deployment and
> they
> > > > > wouldn't expect that the image is missing for the new version.
> > > > >
> > > > > So here we should decide on who will be the deployer of these
> images
> > > with
> > > > > the cache. And the technical solution is smaller problem I would
> say.
> > > > >
> > > > > 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/168b9968deae41
> > > > > 8ca3fd63c63038e896255c6fe8/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 

Re: Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

Romain, of course we know this but there are two groups of users.
First those who use the Maven in docker without CI.
And second of those who integrate the docker container with the CI and they
use the volumes.

The first group of people may freely use the image we are discussing here
because this makes the default build lifecycle faster for them.
For us it means that we will not be seens as "slow Maven", you know what i
mean.

The second group already use the maven images from Carloss.

On Wed, Oct 30, 2019 at 11:12 PM Romain Manni-Bucau 
wrote:

> Ci servers have all cache so it is useless to make the docker pull slow
> with useless versions to then download or not plugins IMHO.
>
> Le mer. 30 oct. 2019 à 22:47, Hervé Boutemy  a écrit
> :
>
> > Le mercredi 30 octobre 2019 14:55:46 CET, vous avez écrit :
> > > Agree we should publish with an asf account and make it part of the
> > release
> > > process.
> > > That said I still fail to see how you can add a relevant cache. Maybe
> > take
> > > the time to review plugin version in a few asf projects (let say
> > > maven-surefire, geronimo-openapi and spark) and check out if it works
> to
> > > cache anything.
> > if we choose one precise version of each plugin, we will never get the
> > version
> > used by a project: IMHO, we need to choose a range for each plugin
> > https://maven.apache.org/plugins/
> > Something like dependency:resolve-plugins should be able to do the job.
> >
> > With a range per plugin, I'd love to see the size of the initial local
> > repository
> > At least, using such an image would require minimal efforts from users,
> > particularly on CI servers
> >
> > Regards,
> >
> > Hervé
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau>
> > > | LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 30 oct. 2019 à 14:31, Tibor Digana  a
> > >
> > > écrit :
> > > > Stephen, yeah something like you do in your scrip but it must not be
> a
> > > > personal owner. Even Carloss is person who makes this deployment to
> > > > DockerHub but his images are used by the entire world and we should
> > decide
> > > > whether we would agree with him to have such images under his
> > > > responsibility or our responsibility as the Apache group. Then the
> > script
> > > > would be official and we can cut the release of Maven and the Docker
> > image
> > > > will be ready for the downloads together with the Maven distribution.
> > So
> > > > the users will always know that it is consistent deployment and they
> > > > wouldn't expect that the image is missing for the new version.
> > > >
> > > > So here we should decide on who will be the deployer of these images
> > with
> > > > the cache. And the technical solution is smaller problem I would say.
> > > >
> > > > 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 
> > > >
> > > > 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/168b9968deae41
> > > > 8ca3fd63c63038e896255c6fe8/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
> > > > > >>
> > > > > >> 

Re: Docker image with initialized local cache saves 50 seconds in startup

[Romain Manni-Bucau]

Ci servers have all cache so it is useless to make the docker pull slow
with useless versions to then download or not plugins IMHO.

Le mer. 30 oct. 2019 à 22:47, Hervé Boutemy  a écrit :

> Le mercredi 30 octobre 2019 14:55:46 CET, vous avez écrit :
> > Agree we should publish with an asf account and make it part of the
> release
> > process.
> > That said I still fail to see how you can add a relevant cache. Maybe
> take
> > the time to review plugin version in a few asf projects (let say
> > maven-surefire, geronimo-openapi and spark) and check out if it works to
> > cache anything.
> if we choose one precise version of each plugin, we will never get the
> version
> used by a project: IMHO, we need to choose a range for each plugin
> https://maven.apache.org/plugins/
> Something like dependency:resolve-plugins should be able to do the job.
>
> With a range per plugin, I'd love to see the size of the initial local
> repository
> At least, using such an image would require minimal efforts from users,
> particularly on CI servers
>
> Regards,
>
> Hervé
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau>
> > | LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 30 oct. 2019 à 14:31, Tibor Digana  a
> >
> > écrit :
> > > Stephen, yeah something like you do in your scrip but it must not be a
> > > personal owner. Even Carloss is person who makes this deployment to
> > > DockerHub but his images are used by the entire world and we should
> decide
> > > whether we would agree with him to have such images under his
> > > responsibility or our responsibility as the Apache group. Then the
> script
> > > would be official and we can cut the release of Maven and the Docker
> image
> > > will be ready for the downloads together with the Maven distribution.
> So
> > > the users will always know that it is consistent deployment and they
> > > wouldn't expect that the image is missing for the new version.
> > >
> > > So here we should decide on who will be the deployer of these images
> with
> > > the cache. And the technical solution is smaller problem I would say.
> > >
> > > 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 
> > >
> > > 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/168b9968deae41
> > > 8ca3fd63c63038e896255c6fe8/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.
> > > > >> >
> > > > >> > 

Re: Fixing LICENCE and NOTICE for binary distributions

[Hervé BOUTEMY]

Le samedi 26 octobre 2019, 23:56:37 CET Enrico Olivelli a écrit :
> Hello,
> as Vladimir reported in [1] we have problems of our binary distributions.
> 
> Short version of the story:
> - we are missing some entries in LICENSE, in my opinion we should cite
> every other ASLv2 licenced project that is not of property of ASF (like
> Plexus), but we are currently skipping them
+1

> - we are not handling correctly some hidden (shaded/relocated) dependencies
+1

> - some of our direct dependencies of Maven Core messed with their LICENSE,
> so the data that we can download automatically (from Maven central) is not
> consistent with other sources (websites for instance)
this one has been fixed for future releases of upstream project, we'll need to 
have a workaround until it is released and we upgrade our dependency

> 
> Please follow up on JIRA for the detailed discussion about every single
> dependency.
> I have also started a branch for the fixes, but it is only a playground for
> me currently as we should decide how the LICENSE/NOTICE/.license files
> should look like  before actually doing this.
+1
little question: what is ".license"?

> 
> I have experience of this kind of discussions in Apache BookKeeper project
> and we came out with this doc [3]
really really interesting, thanks for the pointer

> and a Pull request validation script that
> validates as much as possible those rules.
IIUC, the team maintains the content by hand and the script checks that it is 
still consistent with the current dependencies, that's it?

> 
> I am tyring to understand our dependencies and our packaging of licensing
> material, in order to come with a complete proposal.
> 
> Any thought or suggestion is very welcome !
don't hesitate to share little steps: that will add more opportunities to help 
each other

Regards,

Hervé

> 
> Enrico
> 
> [1] https://issues.apache.org/jira/browse/MNG-6771
> [2] https://github.com/apache/maven/pull/297
> [3] http://bookkeeper.apache.org/community/licensing/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Next Generation Integration Testing for Plugins/Core

[Paul Hammant]

Integration test choices include the excellent Spock as mentioned. I've
used it and it's very solid. Two more choices include:

Another choice is Cuppa - https://github.com/cuppa-framework/cuppa
I've used this too, and it's great - no right-click-run-this-one in
Intellij though. I wish it had more forward momentum, and I'd use the heck
out of it if it did.

Also, there is a segmented use of otherwise *vanilla surefire*:
https://github.com/BuildRadiator/BuildRadiator/blob/master/radiator/pom.xml#L158
is an example.

In that pom, there's three executions of surefire. First unit tests (no
threads, no IO, no FS), Second a few service tests (RestAssured poking a
per-test stood up Jooby web app), Third are a few WebDriver tests with the
same per-test bounce of the Jooby server.

When I first made the above, I made a quick build that shows it all
running. If target/classes/ is full already "mcn install" was 16 seconds
(compile and all three of those test stages). On my old MacBookAir with the
video recorder on, that slowed to 30s. then I refactored it to multi-module
and it is longer still. I'm still pleased with the 16s version though and
roll back the repo to demo that when needed.

I'm quite sure I'll never use Failsafe again.

Re: Next Generation Integration Testing for Plugins/Core

[Paul Hammant]

Oops. Blog entry linking to video of 16s build -
https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/

Re: Docker image with initialized local cache saves 50 seconds in startup

[Hervé Boutemy]

Le mercredi 30 octobre 2019 14:55:46 CET, vous avez écrit :
> Agree we should publish with an asf account and make it part of the release
> process.
> That said I still fail to see how you can add a relevant cache. Maybe take
> the time to review plugin version in a few asf projects (let say
> maven-surefire, geronimo-openapi and spark) and check out if it works to
> cache anything.
if we choose one precise version of each plugin, we will never get the version 
used by a project: IMHO, we need to choose a range for each plugin
https://maven.apache.org/plugins/
Something like dependency:resolve-plugins should be able to do the job.

With a range per plugin, I'd love to see the size of the initial local 
repository
At least, using such an image would require minimal efforts from users, 
particularly on CI servers

Regards,

Hervé

> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> 
> 
> Le mer. 30 oct. 2019 à 14:31, Tibor Digana  a
> 
> écrit :
> > Stephen, yeah something like you do in your scrip but it must not be a
> > personal owner. Even Carloss is person who makes this deployment to
> > DockerHub but his images are used by the entire world and we should decide
> > whether we would agree with him to have such images under his
> > responsibility or our responsibility as the Apache group. Then the script
> > would be official and we can cut the release of Maven and the Docker image
> > will be ready for the downloads together with the Maven distribution. So
> > the users will always know that it is consistent deployment and they
> > wouldn't expect that the image is missing for the new version.
> > 
> > So here we should decide on who will be the deployer of these images with
> > the cache. And the technical solution is smaller problem I would say.
> > 
> > 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 
> > 
> > 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/168b9968deae41
> > 8ca3fd63c63038e896255c6fe8/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  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 

Re: [VOTE] Release Apache Maven JAR Plugin version Y.Z

[Hervé BOUTEMY]

sure :)

Le mardi 29 octobre 2019, 23:16:05 CET Karl Heinz Marbaise a écrit :
> Hi Hervé,
> 
> I think you meant: "[VOTE] Release Apache Maven Source Plugin Version
> 3.2.0"  didn't you ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 29.10.19 22:55, Hervé BOUTEMY wrote:
> > Hi,
> > 
> > We solved 1 issue:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526;
> > version=12345503=Text
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1533/
> > https://repository.apache.org/content/repositories/maven-1533/org/apache/m
> > aven/plugins/maven-jar-plugin/3.2.0/maven-jar-plugin-3.2.0-source-release.
> > zip
> > 
> > Source release checksum(s):
> > maven-jar-plugin-3.2.0-source-release.zip sha512:
> > b84da749dd6ca3a58173ad060a7406bee48ea02d78bc638fcc404c1c31c7c466d5d33890a
> > b549a4edd99efcfebb8926a7955d647a398968c2b1c44393a3bef43
> > 
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/
> > 
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for at least 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Next Generation Integration Testing for Plugins/Core

[Enrico Olivelli]

Karl
(Sorry for top posting)
Thank you very much for moving this forward.
In my personal experience one real blocker in contributions to Maven,
expecially plugins, is to write integration tests.
So having a nice way to create tests is very welcome.
Having a way to run tests as simple unit tests from an IDE allows us to
make a great step forward.

About Groovy vs Java: totally +1 for Java

Just my 2 cents
Enrico

Il mer 30 ott 2019, 21:17 Karl Heinz Marbaise  ha
scritto:

> Hi,
>
> let me conclude some of the things together:
>
> The decision which I have made against Spock was based on several
> reasons:
>
>   * People often tend to write Java code (which is valid), cause
> they don't know Groovy or don't want to learn a new language
> just to write tests.
> This means in the end: Why Groovy? Just use Java.
>
>   * It's much easier for new contributors/devs to get into the
> project if you only need to know Java to write plugins, unit
> tests(also using JUnit5) and integration tests. So removing
> a supplemental hurdle will help.
>
>   * Support for most recent Java versions which is a complete
> blocker for the Apache Maven project, cause we are running builds
> in a very early stage which would block us (see our builds).
> Currently spock is not yet tested/build against JDK11+ ?
> So having a Testing framework which might not work on most
> recent versions is a complete blocker.
>
>   * In earlier days I would have argued to use Spock based
> on the language features but since JDK8 I don't see any advantage
> in using Groovy over Java anymore.
>
>   * Spock does not support parallelizing of tests (full blocker for me)
>
>   * Good IDE Support for Groovy is only given at the moment in
> IDEA IntelliJ and DSL support for Spock also.
>
> That would block many people. This blocker based on the usage
> of a particular IDE is not acceptable for an open source project
> like the Apache Maven Project and with my PMC hat on I would never
> do that.
>
> The command line for executing the tests is at the moment here:
>
> https://github.com/khmarbaise/maven-it-extension/blob/c0823c2afa56b29df1c09f38fe5d73ebcbe4eec3/src/main/java/org/apache/maven/jupiter/extension/ApplicationExecutor.java#L64
>
> which is called from here:
>
> https://github.com/khmarbaise/maven-it-extension/blob/c0823c2afa56b29df1c09f38fe5d73ebcbe4eec3/src/main/java/org/apache/maven/jupiter/extension/MavenITExtension.java#L179
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 30.10.19 16:15, Tibor Digana wrote:
> > Karl, where you define CLI command in each test?
> > Regarding the f/w you have selected. If I had to decide between JUnit5 or
> > Groovy/Spock, I would decide for Spock.
> >
> > On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise 
> > wrote:
> >
> >> Hi to all,
> >>
> >> I've invested some time to get a thing working in a different way which
> >> nags me for a long time.
> >>
> >> Integration tests for maven plugins and for maven core...
> >>
> >> So created a prototype based on a JUnit Jupiter extension.
> >>
> >> The following is the JUnit Jupiter extension (currently very hacky code;
> >> not intended to win a competition for good code!)
> >>
> >> https://github.com/khmarbaise/maven-it-extension
> >>
> >> which contains some documentation which is of course not ready yet...
> >> but the implementation and usage (see maven-ear-plugin) gives me at the
> >> moment already a very good impression how easy it can be to write
> >> integration tests for a maven plugin etc.
> >>
> >> Example from the docs(not 100% working like that yet):
> >>
> >> @MavenIT
> >> class FirstMavenIT {
> >>
> >> @MavenTest
> >> void the_first_test_case(MavenProjectResult result) {
> >>   assertThat(result)
> >> .build()
> >>   .isSuccessful()
> >> .and()
> >> .project()
> >>   .hasTarget()
> >> .withEarFile()
> >>   .containsOnlyOnce("META-INF/MANIFEST.MF")
> >>   .log()
> >> .info().contains("Writing data to file")
> >> .cache()
> >> .withEarFile("G:A:V")
> >> .withPomFile("G:A:V")
> >> .withMetadata().contains("xxx");
> >> }
> >> }
> >>
> >>
> >> I created a branch "maven-it-extension" on Maven EAR Plugin which shows
> >> that it can be used in combination with maven-invoker-plugin:install
> >> goal and using maven-failsafe-plugin to run the tests for
> >> maven-ear-plugin (some of them at the moment. Not migrated all of them
> >> yet).
> >>
> >> Example which already works:
> >>
> >>
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
> >>
> >>
> >> WDYT ?
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, 

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Daniel Kulp]

+1!!!

Dan


> On Oct 29, 2019, at 4:11 PM, Karl Heinz Marbaise  wrote:
> 
> Hi to all,
> 
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-- 
Daniel Kulp
dk...@apache.org  - http://dankulp.com/blog 

Talend Community Coder - http://talend.com 

Re: Next Generation Integration Testing for Plugins/Core

[Karl Heinz Marbaise]

Hi,

let me conclude some of the things together:

The decision which I have made against Spock was based on several
reasons:

 * People often tend to write Java code (which is valid), cause
   they don't know Groovy or don't want to learn a new language
   just to write tests.
   This means in the end: Why Groovy? Just use Java.

 * It's much easier for new contributors/devs to get into the
   project if you only need to know Java to write plugins, unit
   tests(also using JUnit5) and integration tests. So removing
   a supplemental hurdle will help.

 * Support for most recent Java versions which is a complete
   blocker for the Apache Maven project, cause we are running builds
   in a very early stage which would block us (see our builds).
   Currently spock is not yet tested/build against JDK11+ ?
   So having a Testing framework which might not work on most
   recent versions is a complete blocker.

 * In earlier days I would have argued to use Spock based
   on the language features but since JDK8 I don't see any advantage
   in using Groovy over Java anymore.

 * Spock does not support parallelizing of tests (full blocker for me)

 * Good IDE Support for Groovy is only given at the moment in
   IDEA IntelliJ and DSL support for Spock also.

   That would block many people. This blocker based on the usage
   of a particular IDE is not acceptable for an open source project
   like the Apache Maven Project and with my PMC hat on I would never
   do that.

The command line for executing the tests is at the moment here:
https://github.com/khmarbaise/maven-it-extension/blob/c0823c2afa56b29df1c09f38fe5d73ebcbe4eec3/src/main/java/org/apache/maven/jupiter/extension/ApplicationExecutor.java#L64

which is called from here:
https://github.com/khmarbaise/maven-it-extension/blob/c0823c2afa56b29df1c09f38fe5d73ebcbe4eec3/src/main/java/org/apache/maven/jupiter/extension/MavenITExtension.java#L179


Kind regards
Karl Heinz Marbaise

On 30.10.19 16:15, Tibor Digana wrote:

Karl, where you define CLI command in each test?
Regarding the f/w you have selected. If I had to decide between JUnit5 or
Groovy/Spock, I would decide for Spock.

On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise 
wrote:


Hi to all,

I've invested some time to get a thing working in a different way which
nags me for a long time.

Integration tests for maven plugins and for maven core...

So created a prototype based on a JUnit Jupiter extension.

The following is the JUnit Jupiter extension (currently very hacky code;
not intended to win a competition for good code!)

https://github.com/khmarbaise/maven-it-extension

which contains some documentation which is of course not ready yet...
but the implementation and usage (see maven-ear-plugin) gives me at the
moment already a very good impression how easy it can be to write
integration tests for a maven plugin etc.

Example from the docs(not 100% working like that yet):

@MavenIT
class FirstMavenIT {

@MavenTest
void the_first_test_case(MavenProjectResult result) {
  assertThat(result)
.build()
  .isSuccessful()
.and()
.project()
  .hasTarget()
.withEarFile()
  .containsOnlyOnce("META-INF/MANIFEST.MF")
  .log()
.info().contains("Writing data to file")
.cache()
.withEarFile("G:A:V")
.withPomFile("G:A:V")
.withMetadata().contains("xxx");
}
}


I created a branch "maven-it-extension" on Maven EAR Plugin which shows
that it can be used in combination with maven-invoker-plugin:install
goal and using maven-failsafe-plugin to run the tests for
maven-ear-plugin (some of them at the moment. Not migrated all of them
yet).

Example which already works:

https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java


WDYT ?

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Arnaud Héritier]

+1

On Wed, Oct 30, 2019 at 6:10 PM Gabriel Belingueres 
wrote:

> +1
>
> Kind regards
> Gabriel
>
> El mar., 29 de octubre de 2019 17:11, Karl Heinz Marbaise <
> khmarba...@gmx.de>
> escribió:
>
> > Hi to all,
> >
> > based on the discusion this is the formal VOTE to lift the minimum of
> > Maven Core with version 3.7.0 to JDK 8 minimum.
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Gabriel Belingueres]

+1

Kind regards
Gabriel

El mar., 29 de octubre de 2019 17:11, Karl Heinz Marbaise 
escribió:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: ASN.1 ECN

[Christofer Dutz]

Hi Mike,

But I definitely need to re-do the documentation.
http://plc4x.apache.org/developers/code-gen/protocol/mspec.html

I had started writing it before I did a big extension and refactoring …
I really hope I finally will get the chance to work on this again very soon.

Chris

Von: "Beckerle, Mike" 
Datum: Mittwoch, 30. Oktober 2019 um 17:32
An: Christofer Dutz , Julian Feinauer 
, "d...@plc4x.apache.org" 
Betreff: Re: ASN.1 ECN

Chris,

Thanks for this. Very useful. When I look at that  ASN.1 ECN definition I have 
the same reaction to it that I'm sure many non-XML people have to XML Schema 
and DFDL, which is there is much to learn, and so little of it seems relevant 
to the immediate problem. As soon as a description gets complex enough, it 
starts to lose its declarative value.

I think intellectually, we need to find a small, but representative piece of 
data and schema that has what you refer to as the "parsing semantics" of the 
message - the interesting calculations that are fundamental to really 
expressing *all* of the format information.  Then we need to express it in DFDL 
and in ASN.1 ECN best we can so we can have a side-by-side comparison that is 
really helpful.

What is the smallest, simplest format that you have seen that you think 
represents this? Do you have a description of it in MSpec as yet?

Thanks

Mike Beckerle


From: Christofer Dutz 
Sent: Saturday, October 26, 2019 9:42 AM
To: Julian Feinauer ; d...@plc4x.apache.org 

Cc: Beckerle, Mike 
Subject: Re: ASN.1 ECN


Hi Julian and others.



Yes I did have a look as ASN.1, however I had the impression that this only 
specifies the syntax of the packets themselves … it has no means to specify 
parsing semantics.

With MSpec we have the ability to also define these semantics … If we had used 
ASN.1 it would have generated models and parsers with every bit of information 
being included in the POJOs. When serializing we would have had to manually 
handle and prepare all the data.



For example the “implicit” fields … in MSpec we can say “headerLength is 
calculated by taking the total size in bytes, subtract the payload size in 
bytes and subract 2 more” with ASN.1 we would have had to do these caltulations 
ourselves.

Same with the discriminated types … here some data is implicity specified by 
the type itself (discriminators) … also the handling of optional fields and how 
to parse lists/arrays would have been challenging.



My evaluation might not have been 100% correct, but definitions like this did 
sort of scare me:

https://www.itu.int/ITU-T/formal-language/itu-t/x/x692/2008/Example3-EDM.html



Chris





Von: Julian Feinauer 
Datum: Samstag, 26. Oktober 2019 um 10:09
An: "d...@plc4x.apache.org" 
Cc: "Beckerle, Mike" , Christofer Dutz 

Betreff: Re: ASN.1 ECN



Hi Mike,



thanks fort he question which was also asked at ACEU, thus I’m bringing the 
discussion to the dev list.



Can you comment on that Chris? You did most of the evaluation.



Julian



Von: "Beckerle, Mike" 
Datum: Samstag, 26. Oktober 2019 um 06:32
An: Christofer Dutz , Julian Feinauer 

Betreff: ASN.1 ECN



For format description in PLC4X, did you consider ASN.1 Encoding Control 
Notation? This is an ISO standard. I have not used it, but it checks the boxes 
of being a standard, being a grammar + rich library of primitives annotated on 
it, etc.



If you did not consider it, or did and found it unsuitable, I'm interested in 
why.



...mike beckerle

Tresys/Daffodil

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

Not sure I understand it well Tibor, do you encourage to multiply the
number of potential solutions to request more time to contributor to see
how to do things?
Don't think it is good, a single simple solution sounds more promising -
once again from my past experience.

Once again Tibor, all I'm writing is about current state and my experience,
I don't want to block anything but I don't want we do choices on some
"potential" gain and not "validable" hypothesis, if we have a doubt we
should stay simple IMHO.

When I first wrote a maven plugin I checked out the solution to test it and
there was several options, inconsistent between plugins and it was not
helping me to move forward.
Here we have the opportunity to solve that kind of issues for new
contributors and I think it is taking a great direction.
It does not enforce to use @MavenIT but it does not document how to do it 5
different ways which is good.

That said I guess once we have it feature complete we can just do a vote
with a "majority wins" rules and it would be good enough for such a
solution, we don't need to all fully agree on such low level topic I think.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 30 oct. 2019 à 17:26, Tibor Digana  a
écrit :

> Romain, the Java has not made any significant progress in language after
> Java 9. Yes, some JVM features in J13 were really great but not in
> language.
> All fixes about switch-case in several versions, strings, preliminary
> feature. Nothing very progressive for developers! And I think the frequent
> releases/6months were too big hammer.
> The Java should think about these frequent releases because f/w do not
> adapt fast and the developer has no benefit from dropped or preliminary
> features.
> For instance for me J13 has sense oly because of JVM feature JEP351 but not
> because of language and all these dances around ASM versions are just
> because of too frequent Java release with minimum value.
>
> IMO these developers in Maven can use multiple languages and this will be
> then attractive project for the contributors.
> Here Karl developed some new f/w and it will take some time to complete it
> and use it in the Maven ITs. Until then the Spock will change and Java as
> well.
> So he can decide what to use and maybe he will do it so well that JUnit5
> and Spock can be used together.
>
> On Wed, Oct 30, 2019 at 5:03 PM Romain Manni-Bucau 
> wrote:
>
> > @Tibor: do you agree we write the tests with chai (js)? It is the same to
> > use groovy for a java dev today since java caught up its lateness. Not
> > stacking layers and avoiding useless abstractions is the best way to
> enable
> > people to contribute from my experience. As soon as you add a layer which
> > has a step people can find blockers to go upon it will not work (to be
> > explicit here you add a language blocker + an API blocker + a change in
> > native maven conventions which is likely bad for us).
> > Lastly, my point about the java issues is not that it can't be fixed,
> > people there are good enough to fix them all releases after releases, it
> is
> > just that it delays the availability and adoption of spock which means it
> > is not mainstream so contributor friendly.
> > So picking spock woudnt hit our goal.
> >
> > Le mer. 30 oct. 2019 à 16:58, Tibor Digana  a
> > écrit :
> >
> > > Romain, I am glad that you are with me.
> > > Attracting the contributors!
> > >
> > > I hope we all voted for Java 8 sources in Maven Core.
> > > And Spock is the same story.
> > >
> > > Java is the like C++ old style.
> > > Lambda makes this language more moderns a bit.
> > >
> > > Regarding issues with Java 14, all can be fixed, just give the Spock
> the
> > > chance!
> > >
> > >
> > >
> > > On Wed, Oct 30, 2019 at 4:52 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > @Tibor: one goal we should focus on on any new feature is to enable
> us
> > to
> > > > attract more new contributors, spock has the disadvantage to not be
> > > > mainstream at all + to be on groovy which has some issues to support
> > > recent
> > > > java version so it will not help it to be more adopted, therefore I
> > guess
> > > > jupiter is not really a question these days whatever we can think
> about
> > > it.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > 

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Anders Hammar]

+1

/Anders (mobile)

Den tis 29 okt. 2019 20:11Karl Heinz Marbaise  skrev:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Next Generation Integration Testing for Plugins/Core

[Tibor Digana]

Romain, the Java has not made any significant progress in language after
Java 9. Yes, some JVM features in J13 were really great but not in language.
All fixes about switch-case in several versions, strings, preliminary
feature. Nothing very progressive for developers! And I think the frequent
releases/6months were too big hammer.
The Java should think about these frequent releases because f/w do not
adapt fast and the developer has no benefit from dropped or preliminary
features.
For instance for me J13 has sense oly because of JVM feature JEP351 but not
because of language and all these dances around ASM versions are just
because of too frequent Java release with minimum value.

IMO these developers in Maven can use multiple languages and this will be
then attractive project for the contributors.
Here Karl developed some new f/w and it will take some time to complete it
and use it in the Maven ITs. Until then the Spock will change and Java as
well.
So he can decide what to use and maybe he will do it so well that JUnit5
and Spock can be used together.

On Wed, Oct 30, 2019 at 5:03 PM Romain Manni-Bucau 
wrote:

> @Tibor: do you agree we write the tests with chai (js)? It is the same to
> use groovy for a java dev today since java caught up its lateness. Not
> stacking layers and avoiding useless abstractions is the best way to enable
> people to contribute from my experience. As soon as you add a layer which
> has a step people can find blockers to go upon it will not work (to be
> explicit here you add a language blocker + an API blocker + a change in
> native maven conventions which is likely bad for us).
> Lastly, my point about the java issues is not that it can't be fixed,
> people there are good enough to fix them all releases after releases, it is
> just that it delays the availability and adoption of spock which means it
> is not mainstream so contributor friendly.
> So picking spock woudnt hit our goal.
>
> Le mer. 30 oct. 2019 à 16:58, Tibor Digana  a
> écrit :
>
> > Romain, I am glad that you are with me.
> > Attracting the contributors!
> >
> > I hope we all voted for Java 8 sources in Maven Core.
> > And Spock is the same story.
> >
> > Java is the like C++ old style.
> > Lambda makes this language more moderns a bit.
> >
> > Regarding issues with Java 14, all can be fixed, just give the Spock the
> > chance!
> >
> >
> >
> > On Wed, Oct 30, 2019 at 4:52 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > @Tibor: one goal we should focus on on any new feature is to enable us
> to
> > > attract more new contributors, spock has the disadvantage to not be
> > > mainstream at all + to be on groovy which has some issues to support
> > recent
> > > java version so it will not help it to be more adopted, therefore I
> guess
> > > jupiter is not really a question these days whatever we can think about
> > it.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 30 oct. 2019 à 16:16, Tibor Digana  a
> > > écrit :
> > >
> > > > Karl, where you define CLI command in each test?
> > > > Regarding the f/w you have selected. If I had to decide between
> JUnit5
> > or
> > > > Groovy/Spock, I would decide for Spock.
> > > >
> > > > On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise <
> khmarba...@gmx.de
> > >
> > > > wrote:
> > > >
> > > > > Hi to all,
> > > > >
> > > > > I've invested some time to get a thing working in a different way
> > which
> > > > > nags me for a long time.
> > > > >
> > > > > Integration tests for maven plugins and for maven core...
> > > > >
> > > > > So created a prototype based on a JUnit Jupiter extension.
> > > > >
> > > > > The following is the JUnit Jupiter extension (currently very hacky
> > > code;
> > > > > not intended to win a competition for good code!)
> > > > >
> > > > > https://github.com/khmarbaise/maven-it-extension
> > > > >
> > > > > which contains some documentation which is of course not ready
> yet...
> > > > > but the implementation and usage (see maven-ear-plugin) gives me at
> > the
> > > > > moment already a very good impression how easy it can be to write
> > > > > integration tests for a maven plugin etc.
> > > > >
> > > > > Example from the docs(not 100% working like that yet):
> > > > >
> > > > > @MavenIT
> > > > > class FirstMavenIT {
> > > > >
> > > > >@MavenTest
> > > > >void the_first_test_case(MavenProjectResult result) {
> > > > >  assertThat(result)
> > > > >.build()
> > > > >  .isSuccessful()
> > > > >.and()
> > > > >.project()
> > > > >  .hasTarget()
> > > > >.withEarFile()
> > > > >  

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

@Tibor: do you agree we write the tests with chai (js)? It is the same to
use groovy for a java dev today since java caught up its lateness. Not
stacking layers and avoiding useless abstractions is the best way to enable
people to contribute from my experience. As soon as you add a layer which
has a step people can find blockers to go upon it will not work (to be
explicit here you add a language blocker + an API blocker + a change in
native maven conventions which is likely bad for us).
Lastly, my point about the java issues is not that it can't be fixed,
people there are good enough to fix them all releases after releases, it is
just that it delays the availability and adoption of spock which means it
is not mainstream so contributor friendly.
So picking spock woudnt hit our goal.

Le mer. 30 oct. 2019 à 16:58, Tibor Digana  a
écrit :

> Romain, I am glad that you are with me.
> Attracting the contributors!
>
> I hope we all voted for Java 8 sources in Maven Core.
> And Spock is the same story.
>
> Java is the like C++ old style.
> Lambda makes this language more moderns a bit.
>
> Regarding issues with Java 14, all can be fixed, just give the Spock the
> chance!
>
>
>
> On Wed, Oct 30, 2019 at 4:52 PM Romain Manni-Bucau 
> wrote:
>
> > @Tibor: one goal we should focus on on any new feature is to enable us to
> > attract more new contributors, spock has the disadvantage to not be
> > mainstream at all + to be on groovy which has some issues to support
> recent
> > java version so it will not help it to be more adopted, therefore I guess
> > jupiter is not really a question these days whatever we can think about
> it.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 30 oct. 2019 à 16:16, Tibor Digana  a
> > écrit :
> >
> > > Karl, where you define CLI command in each test?
> > > Regarding the f/w you have selected. If I had to decide between JUnit5
> or
> > > Groovy/Spock, I would decide for Spock.
> > >
> > > On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise  >
> > > wrote:
> > >
> > > > Hi to all,
> > > >
> > > > I've invested some time to get a thing working in a different way
> which
> > > > nags me for a long time.
> > > >
> > > > Integration tests for maven plugins and for maven core...
> > > >
> > > > So created a prototype based on a JUnit Jupiter extension.
> > > >
> > > > The following is the JUnit Jupiter extension (currently very hacky
> > code;
> > > > not intended to win a competition for good code!)
> > > >
> > > > https://github.com/khmarbaise/maven-it-extension
> > > >
> > > > which contains some documentation which is of course not ready yet...
> > > > but the implementation and usage (see maven-ear-plugin) gives me at
> the
> > > > moment already a very good impression how easy it can be to write
> > > > integration tests for a maven plugin etc.
> > > >
> > > > Example from the docs(not 100% working like that yet):
> > > >
> > > > @MavenIT
> > > > class FirstMavenIT {
> > > >
> > > >@MavenTest
> > > >void the_first_test_case(MavenProjectResult result) {
> > > >  assertThat(result)
> > > >.build()
> > > >  .isSuccessful()
> > > >.and()
> > > >.project()
> > > >  .hasTarget()
> > > >.withEarFile()
> > > >  .containsOnlyOnce("META-INF/MANIFEST.MF")
> > > >  .log()
> > > >.info().contains("Writing data to file")
> > > >.cache()
> > > >.withEarFile("G:A:V")
> > > >.withPomFile("G:A:V")
> > > >.withMetadata().contains("xxx");
> > > >}
> > > > }
> > > >
> > > >
> > > > I created a branch "maven-it-extension" on Maven EAR Plugin which
> shows
> > > > that it can be used in combination with maven-invoker-plugin:install
> > > > goal and using maven-failsafe-plugin to run the tests for
> > > > maven-ear-plugin (some of them at the moment. Not migrated all of
> them
> > > > yet).
> > > >
> > > > Example which already works:
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
> > > >
> > > >
> > > > WDYT ?
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Next Generation Integration Testing for Plugins/Core

[Tibor Digana]

Romain, I am glad that you are with me.
Attracting the contributors!

I hope we all voted for Java 8 sources in Maven Core.
And Spock is the same story.

Java is the like C++ old style.
Lambda makes this language more moderns a bit.

Regarding issues with Java 14, all can be fixed, just give the Spock the
chance!



On Wed, Oct 30, 2019 at 4:52 PM Romain Manni-Bucau 
wrote:

> @Tibor: one goal we should focus on on any new feature is to enable us to
> attract more new contributors, spock has the disadvantage to not be
> mainstream at all + to be on groovy which has some issues to support recent
> java version so it will not help it to be more adopted, therefore I guess
> jupiter is not really a question these days whatever we can think about it.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 30 oct. 2019 à 16:16, Tibor Digana  a
> écrit :
>
> > Karl, where you define CLI command in each test?
> > Regarding the f/w you have selected. If I had to decide between JUnit5 or
> > Groovy/Spock, I would decide for Spock.
> >
> > On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise 
> > wrote:
> >
> > > Hi to all,
> > >
> > > I've invested some time to get a thing working in a different way which
> > > nags me for a long time.
> > >
> > > Integration tests for maven plugins and for maven core...
> > >
> > > So created a prototype based on a JUnit Jupiter extension.
> > >
> > > The following is the JUnit Jupiter extension (currently very hacky
> code;
> > > not intended to win a competition for good code!)
> > >
> > > https://github.com/khmarbaise/maven-it-extension
> > >
> > > which contains some documentation which is of course not ready yet...
> > > but the implementation and usage (see maven-ear-plugin) gives me at the
> > > moment already a very good impression how easy it can be to write
> > > integration tests for a maven plugin etc.
> > >
> > > Example from the docs(not 100% working like that yet):
> > >
> > > @MavenIT
> > > class FirstMavenIT {
> > >
> > >@MavenTest
> > >void the_first_test_case(MavenProjectResult result) {
> > >  assertThat(result)
> > >.build()
> > >  .isSuccessful()
> > >.and()
> > >.project()
> > >  .hasTarget()
> > >.withEarFile()
> > >  .containsOnlyOnce("META-INF/MANIFEST.MF")
> > >  .log()
> > >.info().contains("Writing data to file")
> > >.cache()
> > >.withEarFile("G:A:V")
> > >.withPomFile("G:A:V")
> > >.withMetadata().contains("xxx");
> > >}
> > > }
> > >
> > >
> > > I created a branch "maven-it-extension" on Maven EAR Plugin which shows
> > > that it can be used in combination with maven-invoker-plugin:install
> > > goal and using maven-failsafe-plugin to run the tests for
> > > maven-ear-plugin (some of them at the moment. Not migrated all of them
> > > yet).
> > >
> > > Example which already works:
> > >
> > >
> >
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
> > >
> > >
> > > WDYT ?
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

Stephen, this is clear to me but we need to move ahead a bit.
Should I start the vote that we will have new project (
github.com/apache/maven-docker) for these purposes?
Or should we talk to Carloss and ask him if he would be fine with deploying
these images in DockerHub?

On Wed, Oct 30, 2019 at 3:21 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> My script is for my cases. I'm just saying it's not rocket science, others
> are doing it already
>
> On Wed, 30 Oct 2019 at 13:31, Tibor Digana  wrote:
>
> > Stephen, yeah something like you do in your scrip but it must not be a
> > personal owner. Even Carloss is person who makes this deployment to
> > DockerHub but his images are used by the entire world and we should
> decide
> > whether we would agree with him to have such images under his
> > responsibility or our responsibility as the Apache group. Then the script
> > would be official and we can cut the release of Maven and the Docker
> image
> > will be ready for the downloads together with the Maven distribution. So
> > the users will always know that it is consistent deployment and they
> > wouldn't expect that the image is missing for the new version.
> >
> > So here we should decide on who will be the deployer of these images with
> > the cache. And the technical solution is smaller problem I would say.
> >
> > 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 
> > 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 
> 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 

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

@Tibor: one goal we should focus on on any new feature is to enable us to
attract more new contributors, spock has the disadvantage to not be
mainstream at all + to be on groovy which has some issues to support recent
java version so it will not help it to be more adopted, therefore I guess
jupiter is not really a question these days whatever we can think about it.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 30 oct. 2019 à 16:16, Tibor Digana  a
écrit :

> Karl, where you define CLI command in each test?
> Regarding the f/w you have selected. If I had to decide between JUnit5 or
> Groovy/Spock, I would decide for Spock.
>
> On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > I've invested some time to get a thing working in a different way which
> > nags me for a long time.
> >
> > Integration tests for maven plugins and for maven core...
> >
> > So created a prototype based on a JUnit Jupiter extension.
> >
> > The following is the JUnit Jupiter extension (currently very hacky code;
> > not intended to win a competition for good code!)
> >
> > https://github.com/khmarbaise/maven-it-extension
> >
> > which contains some documentation which is of course not ready yet...
> > but the implementation and usage (see maven-ear-plugin) gives me at the
> > moment already a very good impression how easy it can be to write
> > integration tests for a maven plugin etc.
> >
> > Example from the docs(not 100% working like that yet):
> >
> > @MavenIT
> > class FirstMavenIT {
> >
> >@MavenTest
> >void the_first_test_case(MavenProjectResult result) {
> >  assertThat(result)
> >.build()
> >  .isSuccessful()
> >.and()
> >.project()
> >  .hasTarget()
> >.withEarFile()
> >  .containsOnlyOnce("META-INF/MANIFEST.MF")
> >  .log()
> >.info().contains("Writing data to file")
> >.cache()
> >.withEarFile("G:A:V")
> >.withPomFile("G:A:V")
> >.withMetadata().contains("xxx");
> >}
> > }
> >
> >
> > I created a branch "maven-it-extension" on Maven EAR Plugin which shows
> > that it can be used in combination with maven-invoker-plugin:install
> > goal and using maven-failsafe-plugin to run the tests for
> > maven-ear-plugin (some of them at the moment. Not migrated all of them
> > yet).
> >
> > Example which already works:
> >
> >
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
> >
> >
> > WDYT ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Next Generation Integration Testing for Plugins/Core

[Karl Heinz Marbaise]

Hi,

On 30.10.19 15:23, Stephen Connolly wrote:

On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau 
wrote:


Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
écrit :


Hi Romain,

On 29.10.19 22:40, Romain Manni-Bucau wrote:

Hi Karl

Not sure id do a MavenIT annotation - test is enough probably - but i
like jupiter style.


MavenIT[1] annotation contains more information like global/local cache,
the default goals which are used for the build, debugging or not (just
to mention some; I think there will be more).

Also so the MavenTest annotation is needed to define specific things for
Maven like activeProfiles etc.

[1]:



https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java


See also:




https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java



You can alias @MavenTest for that no? This is what i had in mind. Like
@ShadeTest decorated with @MavenTest to set defaults.

So you reduce thz number of annotations.

That said it is not a blocker.







Im less exited by assertj but it is probably a habit thing.


I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ
brings clear expression and readable tests in general and gives me a
simple way to create custom assertions to support special parts for a
Maven build like Log file, project structure, target directory contents,
content of archive files etc. ?

like this:

   assertThat(result)
 .project()
   .hasTarget()
 .withEarFile()
.containsOnlyOnce("META-INF/MANIFEST.MF");

I've never seen a assertion framework which makes it possible to write
tests in a more or less fluent way ...



I did use it a few and dropped it since it does not bring much i  most
cases.
Asserts stay simple and chaining them just hit autoformatting limitations
in general.
Also assertj had some dependency conflicts - fixed now IIRC.
So staying minimal was good.

The side note being: do you need it or can you back your dsl with jupiter
assertions? No strong need ;).



What would be your choice?



Just an available model, fluent if you want, but no additional dep.
Default Assertions is enough for most cases, in particular with streams and
lambdas.






Wonder if you evaluated to run in a fake filesystem like jimfs or so

and

enable the pom+files to be defined on the test method?


This is exactly where I have decided against at the moment cause
construction of a full maven project with all it's pom file(s)
directories source code etc. is based on the things I want to solve to
complicated...we already have such things[2] also in plexus testcase you
can do such things or more easier today just use mockito ...



Hmm, this is not comparable.
Mockito is like not writing tests, jimfs is launching a real build on a
fake in memory filesystem, no mocking for maven.



Currently I have gone the path to have a convention where to find the
projects which are used to be tested like maven-invoker-plugin already
does ...and can also being executed manually within the directory
without any change ...helps a lot in case error hunting ...

Can you explain the hint about fake filesystem like jimfs a little bit
more cause I don't know jimfs etc. and what you have in mind?



Jimfs is a FileSystem implementation so if maven uses java.nio.file api
then we can run on an in memory FS and configure it from any metamodel we
want.

It would be close to this sftp testing api

https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32



That would prevent the tests from running Maven in a different JVM... Not
sure if the JUnit extension supports that, but knowing the libraries likely
used I suspect it does



Currently it is not really implemented but prepared
https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/ApplicationExecutor.java

There I can give a parameter for the JVM which will be used..The
MavenITExtension at the moment has not implemented that but it's
prepared to do so...

At the moment it's prototype...


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Next Generation Integration Testing for Plugins/Core

[Tibor Digana]

Karl, where you define CLI command in each test?
Regarding the f/w you have selected. If I had to decide between JUnit5 or
Groovy/Spock, I would decide for Spock.

On Tue, Oct 29, 2019 at 9:47 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> I've invested some time to get a thing working in a different way which
> nags me for a long time.
>
> Integration tests for maven plugins and for maven core...
>
> So created a prototype based on a JUnit Jupiter extension.
>
> The following is the JUnit Jupiter extension (currently very hacky code;
> not intended to win a competition for good code!)
>
> https://github.com/khmarbaise/maven-it-extension
>
> which contains some documentation which is of course not ready yet...
> but the implementation and usage (see maven-ear-plugin) gives me at the
> moment already a very good impression how easy it can be to write
> integration tests for a maven plugin etc.
>
> Example from the docs(not 100% working like that yet):
>
> @MavenIT
> class FirstMavenIT {
>
>@MavenTest
>void the_first_test_case(MavenProjectResult result) {
>  assertThat(result)
>.build()
>  .isSuccessful()
>.and()
>.project()
>  .hasTarget()
>.withEarFile()
>  .containsOnlyOnce("META-INF/MANIFEST.MF")
>  .log()
>.info().contains("Writing data to file")
>.cache()
>.withEarFile("G:A:V")
>.withPomFile("G:A:V")
>.withMetadata().contains("xxx");
>}
> }
>
>
> I created a branch "maven-it-extension" on Maven EAR Plugin which shows
> that it can be used in combination with maven-invoker-plugin:install
> goal and using maven-failsafe-plugin to run the tests for
> maven-ear-plugin (some of them at the moment. Not migrated all of them
> yet).
>
> Example which already works:
>
> https://github.com/apache/maven-ear-plugin/blob/maven-it-extension/src/test/java/org/apache/maven/plugins/ear/it/EARIT.java
>
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Next Generation Integration Testing for Plugins/Core

[Tibor Digana]

well, you have use different JVMs if you expect different env vars.

On Wed, Oct 30, 2019 at 3:23 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau 
> wrote:
>
> > Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
> > écrit :
> >
> > > Hi Romain,
> > >
> > > On 29.10.19 22:40, Romain Manni-Bucau wrote:
> > > > Hi Karl
> > > >
> > > > Not sure id do a MavenIT annotation - test is enough probably - but i
> > > > like jupiter style.
> > >
> > > MavenIT[1] annotation contains more information like global/local
> cache,
> > > the default goals which are used for the build, debugging or not (just
> > > to mention some; I think there will be more).
> > >
> > > Also so the MavenTest annotation is needed to define specific things
> for
> > > Maven like activeProfiles etc.
> > >
> > > [1]:
> > >
> > >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java
> > >
> > > See also:
> > >
> > >
> > >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java
> >
> >
> >
> > You can alias @MavenTest for that no? This is what i had in mind. Like
> > @ShadeTest decorated with @MavenTest to set defaults.
> >
> > So you reduce thz number of annotations.
> >
> > That said it is not a blocker.
> >
> >
> > >
> > >
> > > >
> > > > Im less exited by assertj but it is probably a habit thing.
> > >
> > > I'm not sure if I see your issue with AssertJ. Have you used it?
> AssertJ
> > > brings clear expression and readable tests in general and gives me a
> > > simple way to create custom assertions to support special parts for a
> > > Maven build like Log file, project structure, target directory
> contents,
> > > content of archive files etc. ?
> > >
> > > like this:
> > >
> > >   assertThat(result)
> > > .project()
> > >   .hasTarget()
> > > .withEarFile()
> > >.containsOnlyOnce("META-INF/MANIFEST.MF");
> > >
> > > I've never seen a assertion framework which makes it possible to write
> > > tests in a more or less fluent way ...
> > >
> >
> > I did use it a few and dropped it since it does not bring much i  most
> > cases.
> > Asserts stay simple and chaining them just hit autoformatting limitations
> > in general.
> > Also assertj had some dependency conflicts - fixed now IIRC.
> > So staying minimal was good.
> >
> > The side note being: do you need it or can you back your dsl with jupiter
> > assertions? No strong need ;).
> >
> >
> > > What would be your choice?
> > >
> >
> > Just an available model, fluent if you want, but no additional dep.
> > Default Assertions is enough for most cases, in particular with streams
> and
> > lambdas.
> >
> >
> > >
> > > >
> > > > Wonder if you evaluated to run in a fake filesystem like jimfs or so
> > and
> > > > enable the pom+files to be defined on the test method?
> > >
> > > This is exactly where I have decided against at the moment cause
> > > construction of a full maven project with all it's pom file(s)
> > > directories source code etc. is based on the things I want to solve to
> > > complicated...we already have such things[2] also in plexus testcase
> you
> > > can do such things or more easier today just use mockito ...
> > >
> >
> > Hmm, this is not comparable.
> > Mockito is like not writing tests, jimfs is launching a real build on a
> > fake in memory filesystem, no mocking for maven.
> >
> >
> > > Currently I have gone the path to have a convention where to find the
> > > projects which are used to be tested like maven-invoker-plugin already
> > > does ...and can also being executed manually within the directory
> > > without any change ...helps a lot in case error hunting ...
> > >
> > > Can you explain the hint about fake filesystem like jimfs a little bit
> > > more cause I don't know jimfs etc. and what you have in mind?
> > >
> >
> > Jimfs is a FileSystem implementation so if maven uses java.nio.file api
> > then we can run on an in memory FS and configure it from any metamodel we
> > want.
> >
> > It would be close to this sftp testing api
> >
> >
> https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32
>
>
> That would prevent the tests from running Maven in a different JVM... Not
> sure if the JUnit extension supports that, but knowing the libraries likely
> used I suspect it does
>
>
> >
> >
> >
> > >
> > > [2]:
> > >
> > >
> >
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html
> > >
> > >  > > Goal would be to
> > > > not split setup and asserts (given and then colocalized, then being
> the
> > > > mvn exec).
> > >
> > > Maybe I misunderstand that? Can you give an example ?
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > >
> > > >
> > > > Hope it makes sense.
> > >
> > >
> > > >
> > > > Le mar. 29 oct. 2019 à 

Re: Next Generation Integration Testing for Plugins/Core

[Romain Manni-Bucau]

Good point so guess it can be combined with a config (more a system
properties) to run in memory or forked and therefore the fs can be either
in mem or just populated from the spec (annotations).
Was looking to get something more fluent on the full setup than matching
multiple resources which is - at least for me - a but bothering and looks
old school.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 30 oct. 2019 à 15:23, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau 
> wrote:
>
> > Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
> > écrit :
> >
> > > Hi Romain,
> > >
> > > On 29.10.19 22:40, Romain Manni-Bucau wrote:
> > > > Hi Karl
> > > >
> > > > Not sure id do a MavenIT annotation - test is enough probably - but i
> > > > like jupiter style.
> > >
> > > MavenIT[1] annotation contains more information like global/local
> cache,
> > > the default goals which are used for the build, debugging or not (just
> > > to mention some; I think there will be more).
> > >
> > > Also so the MavenTest annotation is needed to define specific things
> for
> > > Maven like activeProfiles etc.
> > >
> > > [1]:
> > >
> > >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java
> > >
> > > See also:
> > >
> > >
> > >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java
> >
> >
> >
> > You can alias @MavenTest for that no? This is what i had in mind. Like
> > @ShadeTest decorated with @MavenTest to set defaults.
> >
> > So you reduce thz number of annotations.
> >
> > That said it is not a blocker.
> >
> >
> > >
> > >
> > > >
> > > > Im less exited by assertj but it is probably a habit thing.
> > >
> > > I'm not sure if I see your issue with AssertJ. Have you used it?
> AssertJ
> > > brings clear expression and readable tests in general and gives me a
> > > simple way to create custom assertions to support special parts for a
> > > Maven build like Log file, project structure, target directory
> contents,
> > > content of archive files etc. ?
> > >
> > > like this:
> > >
> > >   assertThat(result)
> > > .project()
> > >   .hasTarget()
> > > .withEarFile()
> > >.containsOnlyOnce("META-INF/MANIFEST.MF");
> > >
> > > I've never seen a assertion framework which makes it possible to write
> > > tests in a more or less fluent way ...
> > >
> >
> > I did use it a few and dropped it since it does not bring much i  most
> > cases.
> > Asserts stay simple and chaining them just hit autoformatting limitations
> > in general.
> > Also assertj had some dependency conflicts - fixed now IIRC.
> > So staying minimal was good.
> >
> > The side note being: do you need it or can you back your dsl with jupiter
> > assertions? No strong need ;).
> >
> >
> > > What would be your choice?
> > >
> >
> > Just an available model, fluent if you want, but no additional dep.
> > Default Assertions is enough for most cases, in particular with streams
> and
> > lambdas.
> >
> >
> > >
> > > >
> > > > Wonder if you evaluated to run in a fake filesystem like jimfs or so
> > and
> > > > enable the pom+files to be defined on the test method?
> > >
> > > This is exactly where I have decided against at the moment cause
> > > construction of a full maven project with all it's pom file(s)
> > > directories source code etc. is based on the things I want to solve to
> > > complicated...we already have such things[2] also in plexus testcase
> you
> > > can do such things or more easier today just use mockito ...
> > >
> >
> > Hmm, this is not comparable.
> > Mockito is like not writing tests, jimfs is launching a real build on a
> > fake in memory filesystem, no mocking for maven.
> >
> >
> > > Currently I have gone the path to have a convention where to find the
> > > projects which are used to be tested like maven-invoker-plugin already
> > > does ...and can also being executed manually within the directory
> > > without any change ...helps a lot in case error hunting ...
> > >
> > > Can you explain the hint about fake filesystem like jimfs a little bit
> > > more cause I don't know jimfs etc. and what you have in mind?
> > >
> >
> > Jimfs is a FileSystem implementation so if maven uses java.nio.file api
> > then we can run on an in memory FS and configure it from any metamodel we
> > want.
> >
> > It would be close to this sftp testing api
> >
> >
> https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32
>
>
> That would prevent the tests from 

Re: Next Generation Integration Testing for Plugins/Core

[Stephen Connolly]

On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau 
wrote:

> Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
> écrit :
>
> > Hi Romain,
> >
> > On 29.10.19 22:40, Romain Manni-Bucau wrote:
> > > Hi Karl
> > >
> > > Not sure id do a MavenIT annotation - test is enough probably - but i
> > > like jupiter style.
> >
> > MavenIT[1] annotation contains more information like global/local cache,
> > the default goals which are used for the build, debugging or not (just
> > to mention some; I think there will be more).
> >
> > Also so the MavenTest annotation is needed to define specific things for
> > Maven like activeProfiles etc.
> >
> > [1]:
> >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java
> >
> > See also:
> >
> >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java
>
>
>
> You can alias @MavenTest for that no? This is what i had in mind. Like
> @ShadeTest decorated with @MavenTest to set defaults.
>
> So you reduce thz number of annotations.
>
> That said it is not a blocker.
>
>
> >
> >
> > >
> > > Im less exited by assertj but it is probably a habit thing.
> >
> > I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ
> > brings clear expression and readable tests in general and gives me a
> > simple way to create custom assertions to support special parts for a
> > Maven build like Log file, project structure, target directory contents,
> > content of archive files etc. ?
> >
> > like this:
> >
> >   assertThat(result)
> > .project()
> >   .hasTarget()
> > .withEarFile()
> >.containsOnlyOnce("META-INF/MANIFEST.MF");
> >
> > I've never seen a assertion framework which makes it possible to write
> > tests in a more or less fluent way ...
> >
>
> I did use it a few and dropped it since it does not bring much i  most
> cases.
> Asserts stay simple and chaining them just hit autoformatting limitations
> in general.
> Also assertj had some dependency conflicts - fixed now IIRC.
> So staying minimal was good.
>
> The side note being: do you need it or can you back your dsl with jupiter
> assertions? No strong need ;).
>
>
> > What would be your choice?
> >
>
> Just an available model, fluent if you want, but no additional dep.
> Default Assertions is enough for most cases, in particular with streams and
> lambdas.
>
>
> >
> > >
> > > Wonder if you evaluated to run in a fake filesystem like jimfs or so
> and
> > > enable the pom+files to be defined on the test method?
> >
> > This is exactly where I have decided against at the moment cause
> > construction of a full maven project with all it's pom file(s)
> > directories source code etc. is based on the things I want to solve to
> > complicated...we already have such things[2] also in plexus testcase you
> > can do such things or more easier today just use mockito ...
> >
>
> Hmm, this is not comparable.
> Mockito is like not writing tests, jimfs is launching a real build on a
> fake in memory filesystem, no mocking for maven.
>
>
> > Currently I have gone the path to have a convention where to find the
> > projects which are used to be tested like maven-invoker-plugin already
> > does ...and can also being executed manually within the directory
> > without any change ...helps a lot in case error hunting ...
> >
> > Can you explain the hint about fake filesystem like jimfs a little bit
> > more cause I don't know jimfs etc. and what you have in mind?
> >
>
> Jimfs is a FileSystem implementation so if maven uses java.nio.file api
> then we can run on an in memory FS and configure it from any metamodel we
> want.
>
> It would be close to this sftp testing api
>
> https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32


That would prevent the tests from running Maven in a different JVM... Not
sure if the JUnit extension supports that, but knowing the libraries likely
used I suspect it does


>
>
>
> >
> > [2]:
> >
> >
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html
> >
> >  > > Goal would be to
> > > not split setup and asserts (given and then colocalized, then being the
> > > mvn exec).
> >
> > Maybe I misunderstand that? Can you give an example ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > >
> > > Hope it makes sense.
> >
> >
> > >
> > > Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise  > > > a écrit :
> > >
> > > Hi to all,
> > >
> > > I've invested some time to get a thing working in a different way
> > which
> > > nags me for a long time.
> > >
> > > Integration tests for maven plugins and for maven core...
> > >
> > > So created a prototype based on a JUnit Jupiter extension.
> > >
> > > The following is the JUnit Jupiter extension (currently very hacky
> > code;
> > > not 

Re: Docker image with initialized local cache saves 50 seconds in startup

[Stephen Connolly]

My script is for my cases. I'm just saying it's not rocket science, others
are doing it already

On Wed, 30 Oct 2019 at 13:31, Tibor Digana  wrote:

> Stephen, yeah something like you do in your scrip but it must not be a
> personal owner. Even Carloss is person who makes this deployment to
> DockerHub but his images are used by the entire world and we should decide
> whether we would agree with him to have such images under his
> responsibility or our responsibility as the Apache group. Then the script
> would be official and we can cut the release of Maven and the Docker image
> will be ready for the downloads together with the Maven distribution. So
> the users will always know that it is consistent deployment and they
> wouldn't expect that the image is missing for the new version.
>
> So here we should decide on who will be the deployer of these images with
> the cache. And the technical solution is smaller problem I would say.
>
> 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 
> 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  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
> >
>

Re: Docker image with initialized local cache saves 50 seconds in startup

[Romain Manni-Bucau]

Agree we should publish with an asf account and make it part of the release
process.
That said I still fail to see how you can add a relevant cache. Maybe take
the time to review plugin version in a few asf projects (let say
maven-surefire, geronimo-openapi and spark) and check out if it works to
cache anything.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 30 oct. 2019 à 14:31, Tibor Digana  a
écrit :

> Stephen, yeah something like you do in your scrip but it must not be a
> personal owner. Even Carloss is person who makes this deployment to
> DockerHub but his images are used by the entire world and we should decide
> whether we would agree with him to have such images under his
> responsibility or our responsibility as the Apache group. Then the script
> would be official and we can cut the release of Maven and the Docker image
> will be ready for the downloads together with the Maven distribution. So
> the users will always know that it is consistent deployment and they
> wouldn't expect that the image is missing for the new version.
>
> So here we should decide on who will be the deployer of these images with
> the cache. And the technical solution is smaller problem I would say.
>
> 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 
> 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  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] 

Re: Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

Stephen, yeah something like you do in your scrip but it must not be a
personal owner. Even Carloss is person who makes this deployment to
DockerHub but his images are used by the entire world and we should decide
whether we would agree with him to have such images under his
responsibility or our responsibility as the Apache group. Then the script
would be official and we can cut the release of Maven and the Docker image
will be ready for the downloads together with the Maven distribution. So
the users will always know that it is consistent deployment and they
wouldn't expect that the image is missing for the new version.

So here we should decide on who will be the deployer of these images with
the cache. And the technical solution is smaller problem I would say.

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

Re: Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

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

Re: Docker image with initialized local cache saves 50 seconds in startup

[Stephen Connolly]

On Wed 30 Oct 2019 at 08:21, Tibor Digana  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 
> 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  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

Re: Docker image with initialized local cache saves 50 seconds in startup

[Tibor Digana]

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.

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