Re: Maven Docker Images

2017-10-21 Thread Manfred Moser 
Following up on that remark and my earlier remark that we should NOT make this 
official .. here are my remarks:

- so far the only binaries we assemble and call official are the tar.gz and zip 
archives (and even that is a gray line since official there are only sources 
from Apache)
- we do NOT support (by calling them official) any other binaries such as
  - linux distro versions
  - osx package versions (brews, ports)
  - windows packages
  - sdkman
  - and many others
- the complexity of the docker images is greater than any of the above since it 
includes those factors.. 

Here are a few issues why I would object to this being the official images

- only openjdk and ibm java, no oracle java, no others such as Zulu or whatever
- limited os selection (only alpine and debian and windows from what I can 
tell), no centos, no ubuntu
- binaries are download from a mirror rather than the actual apache servers 
(alternatively maybe could use Central)

These above factors imho show that there is a selection that has been made and 
I do not think we as the Apache Maven project should make this selection.

As such I would suggest to keep it as is. 

An open source project from an individual that provides Maven binaries on 
Docker images. Just happens to be the case that the same person is also a Maven 
PMC (great btw!).

If we make this part of the officially supplied binaries we could also think 
about

- making binaries for various Linux distros in the first place (then we wouldnt 
even need docker images since it could be a one line to install an official 
Maven distro on them)
- supplying binaries to SDKMan, ports, brew, chocolatey and so on
- pull all mojohaus plugins into Apache (they are mostly the same committers..)
- pull other Maven projects in as desired 

You see where this leads... a LOT of work. In my opinion as the Apache Maven 
project we should focus on just that. Maven itself, our current plugins and 
related projects. We all know thats already more work than we can reasonably 
shoulder.. I see no reason to add more.

Manfred



Carlos Sanchez wrote on 2017-10-21 03:59:

> BTW there are possibly more than one image build for each maven version.
> For a variety of reasons, like security issues in OS or to upgrade JDK or
> because docker rebuilds it, so it is not feasible to vote each of them.


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

Re: [VOTE] Release Apache Maven 3.5.2

2017-10-21 Thread Dan Tran 
ouch false alarm,  I forgot to configure the artifactory mirror

Sorry about the noise

-D

On Sat, Oct 21, 2017 at 10:10 AM, Dan Tran  wrote:

> I am not able getting mvn 3.5.2 to download an internal snapshot
> dependency from comp's central artifactory
>
> here is the error
>
> Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
> Could not find artifact com.oracle.linux.x86_64:jre:rpm:1.8.0_151-SNAPSHOT
> at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:355)
> at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
> (DefaultProjectDependenciesResolver.java:202)
>
> No issue with 3.5.0 and 3.5.1
>
> Wonder if anyone else encounters the same issue??
>
> Thanks
>
> -Dan
>
> On Fri, Oct 20, 2017 at 7:35 PM, Mark Derricutt  wrote:
>
>> +1 looking good from here on my projects/releases.
>>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>>
>> On Wed, Oct 18, 2017 at 11:50 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > We solved 26 issues:
>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > version=12338964=Text=12316922
>> >
>> > There are 357 issues left in JIRA for Maven core:
>> > https://issues.apache.org/jira/issues/?jql=project%20%
>> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
>> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>> >
>> > Staging repo:
>> > https://repository.apache.org/content/repositories/maven-1373/
>> >
>> > The distributable binaries and sources can be found here:
>> > https://repository.apache.org/content/repositories/maven-
>> > 1373/org/apache/maven/apache-maven/3.5.2/
>> >
>> > Specifically the zip, tarball and source archives can be found here:
>> > https://repository.apache.org/content/repositories/maven-
>> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.zip
>> > https://repository.apache.org/content/repositories/maven-
>> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.tar.gz
>> > https://repository.apache.org/content/repositories/maven-
>> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.zip
>> > https://repository.apache.org/content/repositories/maven-
>> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.tar.gz
>> >
>> > Source release checksum(s):
>> > apache-maven-3.5.2-src.tar.gz sha1: 97d6d7b18485b7906dd7f313cdd411
>> > 91d16dde46
>> > apache-maven-3.5.2-src.zip: sha1: dc8caa5cdacb400943d2491a020f74
>> 2a518e8f08
>> >
>> > Git tag:
>> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
>> > 138edd61fd100ec658bfa2d307c43b76940a5d7d
>> >
>> > Staging site:
>> > https://maven.apache.org/components/ref/3-LATEST/
>> >
>> > Vote open for 72 hours.
>> >
>> > [ ] +1
>> > [ ] +0
>> > [ ] -1
>> >
>> > Thanks,
>> >
>> > Stephen.
>> >
>>
>
>

Re: [VOTE] Release Apache Maven 3.5.2

2017-10-21 Thread Dan Tran 
I am not able getting mvn 3.5.2 to download an internal snapshot dependency
from comp's central artifactory

here is the error

Caused by: org.eclipse.aether.resolution.DependencyResolutionException:
Could not find artifact com.oracle.linux.x86_64:jre:rpm:1.8.0_151-SNAPSHOT
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
(DefaultRepositorySystem.java:355)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:202)

No issue with 3.5.0 and 3.5.1

Wonder if anyone else encounters the same issue??

Thanks

-Dan

On Fri, Oct 20, 2017 at 7:35 PM, Mark Derricutt  wrote:

> +1 looking good from here on my projects/releases.
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
> On Wed, Oct 18, 2017 at 11:50 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 26 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > version=12338964=Text=12316922
> >
> > There are 357 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1373/
> >
> > The distributable binaries and sources can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1373/org/apache/maven/apache-maven/3.5.2/
> >
> > Specifically the zip, tarball and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1373/org/apache/maven/apache-maven/3.5.2/apache-maven-3.5.2-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.2-src.tar.gz sha1: 97d6d7b18485b7906dd7f313cdd411
> > 91d16dde46
> > apache-maven-3.5.2-src.zip: sha1: dc8caa5cdacb400943d2491a020f74
> 2a518e8f08
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 138edd61fd100ec658bfa2d307c43b76940a5d7d
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Thanks,
> >
> > Stephen.
> >
>

Re: Maven Docker Images

2017-10-21 Thread Carlos Sanchez 
On Sat, Oct 21, 2017 at 3:56 PM, Hervé BOUTEMY 
wrote:

> notice that we vote on source tarballs, not really on binary artifacts
>
> I see the git source changes, both in Dockerfiles and in official-images
> library/
> maven.
> But I don't see when/how images are built
>
> can you explain, please?
>

Docker inc. triggers the builds after git changes in
https://github.com/docker-library/official-images but could also rebuild
whenever they want


>
> Regards,
>
> Hervé
>
> Le samedi 21 octobre 2017, 10:59:45 CEST Carlos Sanchez a écrit :
> > BTW there are possibly more than one image build for each maven version.
> > For a variety of reasons, like security issues in OS or to upgrade JDK or
> > because docker rebuilds it, so it is not feasible to vote each of them.
> >
> > On Sat, Oct 21, 2017, 12:33 Robert Scholte  wrote:
> > > On Sat, 21 Oct 2017 12:19:46 +0200, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > >
> > > wrote:
> > > > Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit :
> > > >> On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY 
> > > >>
> > > >> wrote:
> > > >> > ok, let's switch directly to the Docker case
> > > >> >
> > > >> > I'm not a Docker expert, then I'm discovering things that my be
> > > >>
> > > >> obvious to
> > > >>
> > > >> > others
> > > >> >
> > > >> > IIUC Docker has an "officiel images" project [1] where Carlos
> > > >>
> > > >> provided a
> > > >>
> > > >> > Maven
> > > >> > image [2]: then this image is known as "the official Maven Docker
> > > >>
> > > >> image"
> > > >>
> > > >> > Carlos is an individual, he's also a PMC member of Maven
> > > >> >
> > > >> > what do we want to say: the PMC member has provided an official
> > > >> > Docker
> > > >> > image or
> > > >> > an individual has provided an official Docker image?
> > > >> >
> > > >> > depending on the answer, some way of doing has to be changed (Git
> > > >>
> > > >> location
> > > >>
> > > >> > or
> > > >> > naming of the official image)
> > > >>
> > > >> I’m in favour of creating a repo for the dockerfile, license.txt,
> read
> > > >> me,
> > > >> notices, etc
> > > >
> > > > ok, here I follow
> > > >
> > > >> and follow the standard release vote lifecycle for that
> > > >> dockerfile.
> > > >
> > > > here, I'm not sure this really has a meaning in these official Docker
> > > > images
> > > > cases: IIUC, on a new Maven core release that we want to promote,
> there
> > > > are 2
> > > > actions that are required:
> > > > 1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git
> > > > repo [1]
> > > > 2. have a PR merged to Docker official-images to update the sha1 in
> > > > official-
> > > > images/library/maven [2]
> > > >
> > > > Between the 2 steps, we can choose to vote, or not to vote, I don't
> know
> > > > what's the best: we already voted for the Maven release that gets the
> > > > new
> > > > recommended version.
> > > > What is important to me is that anybody from the PMC can do the PR to
> > > > Docker
> > > > official-images (if we decide that we maintain the official image,
> not
> > > > only
> > > > Carlos): there is not specific credentials
> > > >
> > > > One thing I see is that we can automate a check that the current
> > > > official-image
> > > > is our currently recommended Maven version: it's just about adding a
> new
> > > > check
> > > > to dist-tool-plugin that will be checked every day by Jenkins job [3]
> > >
> > > Without talking in solutions, we have this general question: Are we
> > > informing others by their format or are we offering some generic
> message
> > > for others to make them aware there's a new version.
> > >
> > > This disttool solution sounds like the first one (we trigger Carlos in
> > > some way so he can make a new image), which is exactly what SDKMan
> asked
> > > us to do.
> > >
> > > IMHO whatever we do for Docker, we should do the same for SDKMan and
> offer
> > > that solution for other interested parties.
> > >
> > > Robert
> > >
> > > > [1] https://github.com/carlossg/docker-maven
> > > >
> > > > [2]
> > >
> > > https://github.com/docker-library/official-images/blob/
> master/library/mave
> > > n
> > >
> > > > [3]
> > > > https://builds.apache.org/view/M-R/view/Maven/job/dist-
> tool-plugin/site/
> > > >
> > > >> If we want that dockerfile in Maven-core repo, i’m Fine with that
> too
> > > >
> > > > given the content, a separate repo more reasonable
> > > >
> > > >> Now the other question is how to get the image from that dockerfile
> > > >> into
> > > >> docker...
> > > >
> > > > IIUC, that's the second point I wrote: we don't really put the image
> but
> > > > update a commit reference to our Dockerfiles
> > > >
> > > >> I’m happy for Carlos to continue doing in a personal capacity...
> > > >
> > > > +1
> > > > I'd be happy to just have this as an official PMC asset, with Carlos
> as
> > > > our
> > > > expert who wrote the subtle bunch of images, since IIUC, it's not

Re: Maven Docker Images

2017-10-21 Thread Hervé BOUTEMY 
notice that we vote on source tarballs, not really on binary artifacts

I see the git source changes, both in Dockerfiles and in official-images 
library/
maven.
But I don't see when/how images are built

can you explain, please?

Regards,

Hervé

Le samedi 21 octobre 2017, 10:59:45 CEST Carlos Sanchez a écrit :
> BTW there are possibly more than one image build for each maven version.
> For a variety of reasons, like security issues in OS or to upgrade JDK or
> because docker rebuilds it, so it is not feasible to vote each of them.
> 
> On Sat, Oct 21, 2017, 12:33 Robert Scholte  wrote:
> > On Sat, 21 Oct 2017 12:19:46 +0200, Hervé BOUTEMY 
> > 
> > wrote:
> > > Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit :
> > >> On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY 
> > >> 
> > >> wrote:
> > >> > ok, let's switch directly to the Docker case
> > >> > 
> > >> > I'm not a Docker expert, then I'm discovering things that my be
> > >> 
> > >> obvious to
> > >> 
> > >> > others
> > >> > 
> > >> > IIUC Docker has an "officiel images" project [1] where Carlos
> > >> 
> > >> provided a
> > >> 
> > >> > Maven
> > >> > image [2]: then this image is known as "the official Maven Docker
> > >> 
> > >> image"
> > >> 
> > >> > Carlos is an individual, he's also a PMC member of Maven
> > >> > 
> > >> > what do we want to say: the PMC member has provided an official
> > >> > Docker
> > >> > image or
> > >> > an individual has provided an official Docker image?
> > >> > 
> > >> > depending on the answer, some way of doing has to be changed (Git
> > >> 
> > >> location
> > >> 
> > >> > or
> > >> > naming of the official image)
> > >> 
> > >> I’m in favour of creating a repo for the dockerfile, license.txt, read
> > >> me,
> > >> notices, etc
> > > 
> > > ok, here I follow
> > > 
> > >> and follow the standard release vote lifecycle for that
> > >> dockerfile.
> > > 
> > > here, I'm not sure this really has a meaning in these official Docker
> > > images
> > > cases: IIUC, on a new Maven core release that we want to promote, there
> > > are 2
> > > actions that are required:
> > > 1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git
> > > repo [1]
> > > 2. have a PR merged to Docker official-images to update the sha1 in
> > > official-
> > > images/library/maven [2]
> > > 
> > > Between the 2 steps, we can choose to vote, or not to vote, I don't know
> > > what's the best: we already voted for the Maven release that gets the
> > > new
> > > recommended version.
> > > What is important to me is that anybody from the PMC can do the PR to
> > > Docker
> > > official-images (if we decide that we maintain the official image, not
> > > only
> > > Carlos): there is not specific credentials
> > > 
> > > One thing I see is that we can automate a check that the current
> > > official-image
> > > is our currently recommended Maven version: it's just about adding a new
> > > check
> > > to dist-tool-plugin that will be checked every day by Jenkins job [3]
> > 
> > Without talking in solutions, we have this general question: Are we
> > informing others by their format or are we offering some generic message
> > for others to make them aware there's a new version.
> > 
> > This disttool solution sounds like the first one (we trigger Carlos in
> > some way so he can make a new image), which is exactly what SDKMan asked
> > us to do.
> > 
> > IMHO whatever we do for Docker, we should do the same for SDKMan and offer
> > that solution for other interested parties.
> > 
> > Robert
> > 
> > > [1] https://github.com/carlossg/docker-maven
> > > 
> > > [2]
> > 
> > https://github.com/docker-library/official-images/blob/master/library/mave
> > n
> > 
> > > [3]
> > > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> > > 
> > >> If we want that dockerfile in Maven-core repo, i’m Fine with that too
> > > 
> > > given the content, a separate repo more reasonable
> > > 
> > >> Now the other question is how to get the image from that dockerfile
> > >> into
> > >> docker...
> > > 
> > > IIUC, that's the second point I wrote: we don't really put the image but
> > > update a commit reference to our Dockerfiles
> > > 
> > >> I’m happy for Carlos to continue doing in a personal capacity...
> > > 
> > > +1
> > > I'd be happy to just have this as an official PMC asset, with Carlos as
> > > our
> > > expert who wrote the subtle bunch of images, since IIUC, it's not really
> > > one
> > > image but a collection that one can choose from
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > >> So i’d be
> > >> 
> > >> “The dockerfile has been released by the Maven project and a member of
> > >> the
> > >> PMC has uploaded the image”
> > >> 
> > >> > Regards,
> > >> > 
> > >> > Hervé
> > >> > 
> > >> > [1] https://github.com/docker-library/official-images
> > >> > 
> > >> > [2]
> > 
> >

Re: Maven Docker Images

2017-10-21 Thread Hervé BOUTEMY 
Le samedi 21 octobre 2017, 12:32:54 CEST Robert Scholte a écrit :
> > One thing I see is that we can automate a check that the current
> > official-image
> > is our currently recommended Maven version: it's just about adding a new
> > check
> > to dist-tool-plugin that will be checked every day by Jenkins job [3]
> 
> Without talking in solutions, we have this general question: Are we
> informing others by their format or are we offering some generic message
> for others to make them aware there's a new version.
> 
> This disttool solution sounds like the first one (we trigger Carlos in
> some way so he can make a new image), which is exactly what SDKMan asked
> us to do.
Currently the tool is meant to check that the full release process has been 
done and tell if a step was forgotten. The tool does not trigger someone 
specifically: it triggers a build failure, with an explanation on what to do to 
fix. If nobody cares about the job failure (which happens often), nothing gets 
done: in general, I do care, then either I ping the offender (some of you 
Maven devs know what I'm talking about :) ), either I just do the job.

I don't know if adding some code and configuration to send an email to someone 
would be easy: I don't know if there is a smtp server available on Jenkins 
nodes.

> 
> IMHO whatever we do for Docker, we should do the same for SDKMan and offer
> that solution for other interested parties.
summary: there is a little difference between helping a Maven dev doing the 
full release process (by checking forgotten steps), given he's credentials to 
do everything, and pinging someone who is the only one to have the credentials

Regards,

Hervé

> 
> Robert
> 
> > [1] https://github.com/carlossg/docker-maven
> > 
> > [2]
> > https://github.com/docker-library/official-images/blob/master/library/mave
> > n
> > 
> > [3]
> > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> > 
> >> If we want that dockerfile in Maven-core repo, i’m Fine with that too
> > 
> > given the content, a separate repo more reasonable
> > 
> >> Now the other question is how to get the image from that dockerfile into
> >> docker...
> > 
> > IIUC, that's the second point I wrote: we don't really put the image but
> > update a commit reference to our Dockerfiles
> > 
> >> I’m happy for Carlos to continue doing in a personal capacity...
> > 
> > +1
> > I'd be happy to just have this as an official PMC asset, with Carlos as
> > our
> > expert who wrote the subtle bunch of images, since IIUC, it's not really
> > one
> > image but a collection that one can choose from
> > 
> > Regards,
> > 
> > Hervé
> > 
> >> So i’d be
> >> 
> >> “The dockerfile has been released by the Maven project and a member of
> >> the
> >> PMC has uploaded the image”
> >> 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > [1] https://github.com/docker-library/official-images
> >> > 
> >> > [2]
> >> 
> >> https://github.com/docker-library/official-images/blob/master/library/mav
> >> e
> >> 
> >> > n
> >> > 
> >> > Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> >> > > From my perspective it is just like sdkman including the
> >> 
> >> conclusion. We
> >> 
> >> > have
> >> > 
> >> > > other tasks at our hands, maintaining a docker images is not
> >> 
> >> something
> >> 
> >> > > we
> >> > > should bother with. However needs one can easily create one and
> >> 
> >> there
> >> 
> >> > will
> >> > 
> >> > > be thousands of variations different users want.
> >> > > 
> >> > > Let them create it on their own.
> >> > > 
> >> > > Manfred
> >> > > 
> >> > > Hervé BOUTEMY wrote on 2017-10-20 18:46:
> >> > > > true, from a general perspective, it's like sdkman
> >> > > > 
> >> > > > we need to discuss then decide if we want to maintain Maven Docker
> >> > > > integration (contrary to our current decision to not maintain
> >> 
> >> Maven
> >> 
> >> > > > sdkman integration but let sdkman community do it)
> >> > > > 
> >> > > > can we think about a general solution? perhaps not really a
> >> 
> >> solution,
> >> 
> >> > but
> >> > 
> >> > > > a
> >> > > > decision process, yes
> >> > > > 
> >> > > > to me, on each tool integration, there are key decision drivers:
> >> > > > - importance of the tool on the market
> >> > > > - interest of Maven devs to actually do integration maintenance
> >> > > > - complexity of integration, technical prerequisites (with IDEs,
> >> 
> >> for
> >> 
> >> > > > example, a dedicated independant project like m2e is necessary)
> >> > > > - time factor: things evolve over time (e.g. 2 years ago, Docker
> >> 
> >> was
> >> 
> >> > not
> >> > 
> >> > > > what it is nowadays)
> >> > > > 
> >> > > > any other key driver to document?
> >> > > > 
> >> > > > once done, we'll discuss more precisely about the Docker
> >> 
> >> integration
> >> 
> >> > case
> >> > 
> >> > > > and probably finish with a vote :)
> >> > > > 
> >> > > > Regards,
> >> > > > 
> >> > > > Hervé
> >> > > > 
> >> > > > Le vendredi 20

Re: moving GitHub issue notifications to issues@maven.a.o

2017-10-21 Thread Uwe Barthel 
+1 (non binding)

-- 
bart...@x-reizend.de


> On 21. Oct 2017, at 12:22, Hervé BOUTEMY  wrote:
> 
> Currently, comments are sent to dev@maven.a.o
> 
> For our classical official Jira issue tracker, notifications are sent to 
> issues@maven.a.o
> 
> If nobody objects (72h as usual), I'll ask infra to switch GitHub issue 
> notifications to isseus@maven.a.o
> 
> Regards,
> 
> Hervé
> 
> -
> 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: moving GitHub issue notifications to issues@maven.a.o

2017-10-21 Thread Olivier Lamy 
+1

On 21 October 2017 at 21:23, Robert Scholte  wrote:

> +1
>
>
> On Sat, 21 Oct 2017 12:22:47 +0200, Hervé BOUTEMY 
> wrote:
>
> Currently, comments are sent to dev@maven.a.o
>>
>> For our classical official Jira issue tracker, notifications are sent to
>> issues@maven.a.o
>>
>> If nobody objects (72h as usual), I'll ask infra to switch GitHub issue
>> notifications to isseus@maven.a.o
>>
>> Regards,
>>
>> Hervé
>>
>> -
>> 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
>
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Maven Docker Images

2017-10-21 Thread Carlos Sanchez 
BTW there are possibly more than one image build for each maven version.
For a variety of reasons, like security issues in OS or to upgrade JDK or
because docker rebuilds it, so it is not feasible to vote each of them.

On Sat, Oct 21, 2017, 12:33 Robert Scholte  wrote:

> On Sat, 21 Oct 2017 12:19:46 +0200, Hervé BOUTEMY 
> wrote:
>
> > Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit :
> >> On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY 
> >> wrote:
> >> > ok, let's switch directly to the Docker case
> >> >
> >> > I'm not a Docker expert, then I'm discovering things that my be
> >> obvious to
> >> > others
> >> >
> >> > IIUC Docker has an "officiel images" project [1] where Carlos
> >> provided a
> >> > Maven
> >> > image [2]: then this image is known as "the official Maven Docker
> >> image"
> >> > Carlos is an individual, he's also a PMC member of Maven
> >> >
> >> > what do we want to say: the PMC member has provided an official Docker
> >> > image or
> >> > an individual has provided an official Docker image?
> >> >
> >> > depending on the answer, some way of doing has to be changed (Git
> >> location
> >> > or
> >> > naming of the official image)
> >>
> >> I’m in favour of creating a repo for the dockerfile, license.txt, read
> >> me,
> >> notices, etc
> > ok, here I follow
> >
> >> and follow the standard release vote lifecycle for that
> >> dockerfile.
> > here, I'm not sure this really has a meaning in these official Docker
> > images
> > cases: IIUC, on a new Maven core release that we want to promote, there
> > are 2
> > actions that are required:
> > 1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git
> > repo [1]
> > 2. have a PR merged to Docker official-images to update the sha1 in
> > official-
> > images/library/maven [2]
> >
> > Between the 2 steps, we can choose to vote, or not to vote, I don't know
> > what's the best: we already voted for the Maven release that gets the new
> > recommended version.
> > What is important to me is that anybody from the PMC can do the PR to
> > Docker
> > official-images (if we decide that we maintain the official image, not
> > only
> > Carlos): there is not specific credentials
> >
> > One thing I see is that we can automate a check that the current
> > official-image
> > is our currently recommended Maven version: it's just about adding a new
> > check
> > to dist-tool-plugin that will be checked every day by Jenkins job [3]
>
> Without talking in solutions, we have this general question: Are we
> informing others by their format or are we offering some generic message
> for others to make them aware there's a new version.
>
> This disttool solution sounds like the first one (we trigger Carlos in
> some way so he can make a new image), which is exactly what SDKMan asked
> us to do.
>
> IMHO whatever we do for Docker, we should do the same for SDKMan and offer
> that solution for other interested parties.
>
> Robert
>
> >
> > [1] https://github.com/carlossg/docker-maven
> >
> > [2]
> >
> https://github.com/docker-library/official-images/blob/master/library/maven
> >
> > [3]
> > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> >
> >>
> >> If we want that dockerfile in Maven-core repo, i’m Fine with that too
> > given the content, a separate repo more reasonable
> >
> >>
> >> Now the other question is how to get the image from that dockerfile into
> >> docker...
> > IIUC, that's the second point I wrote: we don't really put the image but
> > update a commit reference to our Dockerfiles
> >
> >>
> >> I’m happy for Carlos to continue doing in a personal capacity...
> > +1
> > I'd be happy to just have this as an official PMC asset, with Carlos as
> > our
> > expert who wrote the subtle bunch of images, since IIUC, it's not really
> > one
> > image but a collection that one can choose from
> >
> > Regards,
> >
> > Hervé
> >
> >>
> >> So i’d be
> >>
> >> “The dockerfile has been released by the Maven project and a member of
> >> the
> >> PMC has uploaded the image”
> >>
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > [1] https://github.com/docker-library/official-images
> >> >
> >> > [2]
> >> >
> >>
> https://github.com/docker-library/official-images/blob/master/library/mave
> >> > n
> >> >
> >> > Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> >> > > From my perspective it is just like sdkman including the
> >> conclusion. We
> >> >
> >> > have
> >> >
> >> > > other tasks at our hands, maintaining a docker images is not
> >> something
> >> > > we
> >> > > should bother with. However needs one can easily create one and
> >> there
> >> >
> >> > will
> >> >
> >> > > be thousands of variations different users want.
> >> > >
> >> > > Let them create it on their own.
> >> > >
> >> > > Manfred
> >> > >
> >> > > Hervé BOUTEMY wrote on 2017-10-20 18:46:
> >> > > > true, from a general perspective, it's like sdkman
> >> >

Re: Maven Docker Images

2017-10-21 Thread Robert Scholte 
On Sat, 21 Oct 2017 12:19:46 +0200, Hervé BOUTEMY   
wrote:



Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit :
On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY   
wrote:

> ok, let's switch directly to the Docker case
>
> I'm not a Docker expert, then I'm discovering things that my be  
obvious to

> others
>
> IIUC Docker has an "officiel images" project [1] where Carlos  
provided a

> Maven
> image [2]: then this image is known as "the official Maven Docker  
image"

> Carlos is an individual, he's also a PMC member of Maven
>
> what do we want to say: the PMC member has provided an official Docker
> image or
> an individual has provided an official Docker image?
>
> depending on the answer, some way of doing has to be changed (Git  
location

> or
> naming of the official image)

I’m in favour of creating a repo for the dockerfile, license.txt, read  
me,

notices, etc

ok, here I follow


and follow the standard release vote lifecycle for that
dockerfile.
here, I'm not sure this really has a meaning in these official Docker  
images
cases: IIUC, on a new Maven core release that we want to promote, there  
are 2

actions that are required:
1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git  
repo [1]
2. have a PR merged to Docker official-images to update the sha1 in  
official-

images/library/maven [2]

Between the 2 steps, we can choose to vote, or not to vote, I don't know
what's the best: we already voted for the Maven release that gets the new
recommended version.
What is important to me is that anybody from the PMC can do the PR to  
Docker
official-images (if we decide that we maintain the official image, not  
only

Carlos): there is not specific credentials

One thing I see is that we can automate a check that the current  
official-image
is our currently recommended Maven version: it's just about adding a new  
check

to dist-tool-plugin that will be checked every day by Jenkins job [3]


Without talking in solutions, we have this general question: Are we  
informing others by their format or are we offering some generic message  
for others to make them aware there's a new version.


This disttool solution sounds like the first one (we trigger Carlos in  
some way so he can make a new image), which is exactly what SDKMan asked  
us to do.


IMHO whatever we do for Docker, we should do the same for SDKMan and offer  
that solution for other interested parties.


Robert



[1] https://github.com/carlossg/docker-maven

[2]  
https://github.com/docker-library/official-images/blob/master/library/maven


[3]  
https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/




If we want that dockerfile in Maven-core repo, i’m Fine with that too

given the content, a separate repo more reasonable



Now the other question is how to get the image from that dockerfile into
docker...

IIUC, that's the second point I wrote: we don't really put the image but
update a commit reference to our Dockerfiles



I’m happy for Carlos to continue doing in a personal capacity...

+1
I'd be happy to just have this as an official PMC asset, with Carlos as  
our
expert who wrote the subtle bunch of images, since IIUC, it's not really  
one

image but a collection that one can choose from

Regards,

Hervé



So i’d be

“The dockerfile has been released by the Maven project and a member of  
the

PMC has uploaded the image”

> Regards,
>
> Hervé
>
> [1] https://github.com/docker-library/official-images
>
> [2]
>  
https://github.com/docker-library/official-images/blob/master/library/mave

> n
>
> Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> > From my perspective it is just like sdkman including the  
conclusion. We

>
> have
>
> > other tasks at our hands, maintaining a docker images is not  
something

> > we
> > should bother with. However needs one can easily create one and  
there

>
> will
>
> > be thousands of variations different users want.
> >
> > Let them create it on their own.
> >
> > Manfred
> >
> > Hervé BOUTEMY wrote on 2017-10-20 18:46:
> > > true, from a general perspective, it's like sdkman
> > >
> > > we need to discuss then decide if we want to maintain Maven Docker
> > > integration (contrary to our current decision to not maintain  
Maven

> > > sdkman integration but let sdkman community do it)
> > >
> > > can we think about a general solution? perhaps not really a  
solution,

>
> but
>
> > > a
> > > decision process, yes
> > >
> > > to me, on each tool integration, there are key decision drivers:
> > > - importance of the tool on the market
> > > - interest of Maven devs to actually do integration maintenance
> > > - complexity of integration, technical prerequisites (with IDEs,  
for

> > > example, a dedicated independant project like m2e is necessary)
> > > - time factor: things evolve over time (e.g. 2 years ago, Docker  
was

>
> not
>
> > > what it is nowadays)
> > >
> > > any

Re: moving GitHub issue notifications to issues@maven.a.o

2017-10-21 Thread Robert Scholte 

+1

On Sat, 21 Oct 2017 12:22:47 +0200, Hervé BOUTEMY   
wrote:



Currently, comments are sent to dev@maven.a.o

For our classical official Jira issue tracker, notifications are sent to
issues@maven.a.o

If nobody objects (72h as usual), I'll ask infra to switch GitHub issue
notifications to isseus@maven.a.o

Regards,

Hervé

-
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

moving GitHub issue notifications to issues@maven.a.o

2017-10-21 Thread Hervé BOUTEMY 
Currently, comments are sent to dev@maven.a.o

For our classical official Jira issue tracker, notifications are sent to 
issues@maven.a.o

If nobody objects (72h as usual), I'll ask infra to switch GitHub issue 
notifications to isseus@maven.a.o

Regards,

Hervé

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

Re: Maven Docker Images

2017-10-21 Thread Hervé BOUTEMY 
Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit :
> On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY  wrote:
> > ok, let's switch directly to the Docker case
> > 
> > I'm not a Docker expert, then I'm discovering things that my be obvious to
> > others
> > 
> > IIUC Docker has an "officiel images" project [1] where Carlos provided a
> > Maven
> > image [2]: then this image is known as "the official Maven Docker image"
> > Carlos is an individual, he's also a PMC member of Maven
> > 
> > what do we want to say: the PMC member has provided an official Docker
> > image or
> > an individual has provided an official Docker image?
> > 
> > depending on the answer, some way of doing has to be changed (Git location
> > or
> > naming of the official image)
> 
> I’m in favour of creating a repo for the dockerfile, license.txt, read me,
> notices, etc
ok, here I follow

> and follow the standard release vote lifecycle for that
> dockerfile.
here, I'm not sure this really has a meaning in these official Docker images 
cases: IIUC, on a new Maven core release that we want to promote, there are 2 
actions that are required:
1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git repo [1]
2. have a PR merged to Docker official-images to update the sha1 in official-
images/library/maven [2]

Between the 2 steps, we can choose to vote, or not to vote, I don't know 
what's the best: we already voted for the Maven release that gets the new 
recommended version.
What is important to me is that anybody from the PMC can do the PR to Docker 
official-images (if we decide that we maintain the official image, not only 
Carlos): there is not specific credentials

One thing I see is that we can automate a check that the current official-image 
is our currently recommended Maven version: it's just about adding a new check 
to dist-tool-plugin that will be checked every day by Jenkins job [3]

[1] https://github.com/carlossg/docker-maven

[2] https://github.com/docker-library/official-images/blob/master/library/maven

[3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/

> 
> If we want that dockerfile in Maven-core repo, i’m Fine with that too
given the content, a separate repo more reasonable

> 
> Now the other question is how to get the image from that dockerfile into
> docker...
IIUC, that's the second point I wrote: we don't really put the image but 
update a commit reference to our Dockerfiles

> 
> I’m happy for Carlos to continue doing in a personal capacity...
+1
I'd be happy to just have this as an official PMC asset, with Carlos as our 
expert who wrote the subtle bunch of images, since IIUC, it's not really one 
image but a collection that one can choose from

Regards,

Hervé

> 
> So i’d be
> 
> “The dockerfile has been released by the Maven project and a member of the
> PMC has uploaded the image”
> 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://github.com/docker-library/official-images
> > 
> > [2]
> > https://github.com/docker-library/official-images/blob/master/library/mave
> > n
> > 
> > Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> > > From my perspective it is just like sdkman including the conclusion. We
> > 
> > have
> > 
> > > other tasks at our hands, maintaining a docker images is not something
> > > we
> > > should bother with. However needs one can easily create one and there
> > 
> > will
> > 
> > > be thousands of variations different users want.
> > > 
> > > Let them create it on their own.
> > > 
> > > Manfred
> > > 
> > > Hervé BOUTEMY wrote on 2017-10-20 18:46:
> > > > true, from a general perspective, it's like sdkman
> > > > 
> > > > we need to discuss then decide if we want to maintain Maven Docker
> > > > integration (contrary to our current decision to not maintain Maven
> > > > sdkman integration but let sdkman community do it)
> > > > 
> > > > can we think about a general solution? perhaps not really a solution,
> > 
> > but
> > 
> > > > a
> > > > decision process, yes
> > > > 
> > > > to me, on each tool integration, there are key decision drivers:
> > > > - importance of the tool on the market
> > > > - interest of Maven devs to actually do integration maintenance
> > > > - complexity of integration, technical prerequisites (with IDEs, for
> > > > example, a dedicated independant project like m2e is necessary)
> > > > - time factor: things evolve over time (e.g. 2 years ago, Docker was
> > 
> > not
> > 
> > > > what it is nowadays)
> > > > 
> > > > any other key driver to document?
> > > > 
> > > > once done, we'll discuss more precisely about the Docker integration
> > 
> > case
> > 
> > > > and probably finish with a vote :)
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 20 octobre 2017, 11:30:49 CEST Robert Scholte a écrit :
> > > >> Isn't this actually the same case as sdkman[1]?
> > > >> Just wondering if we need to think about a general solution instead
> > >

Re: Maven Docker Images

2017-10-21 Thread Stephen Connolly 
On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY  wrote:

> ok, let's switch directly to the Docker case
>
> I'm not a Docker expert, then I'm discovering things that my be obvious to
> others
>
> IIUC Docker has an "officiel images" project [1] where Carlos provided a
> Maven
> image [2]: then this image is known as "the official Maven Docker image"
> Carlos is an individual, he's also a PMC member of Maven
>
> what do we want to say: the PMC member has provided an official Docker
> image or
> an individual has provided an official Docker image?
>
> depending on the answer, some way of doing has to be changed (Git location
> or
> naming of the official image)


I’m in favour of creating a repo for the dockerfile, license.txt, read me,
notices, etc and follow the standard release vote lifecycle for that
dockerfile.

If we want that dockerfile in Maven-core repo, i’m Fine with that too

Now the other question is how to get the image from that dockerfile into
docker...

I’m happy for Carlos to continue doing in a personal capacity...

So i’d be

“The dockerfile has been released by the Maven project and a member of the
PMC has uploaded the image”


>
> Regards,
>
> Hervé
>
> [1] https://github.com/docker-library/official-images
>
> [2]
> https://github.com/docker-library/official-images/blob/master/library/maven
>
> Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> > From my perspective it is just like sdkman including the conclusion. We
> have
> > other tasks at our hands, maintaining a docker images is not something we
> > should bother with. However needs one can easily create one and there
> will
> > be thousands of variations different users want.
> >
> > Let them create it on their own.
> >
> > Manfred
> >
> > Hervé BOUTEMY wrote on 2017-10-20 18:46:
> > > true, from a general perspective, it's like sdkman
> > >
> > > we need to discuss then decide if we want to maintain Maven Docker
> > > integration (contrary to our current decision to not maintain Maven
> > > sdkman integration but let sdkman community do it)
> > >
> > > can we think about a general solution? perhaps not really a solution,
> but
> > > a
> > > decision process, yes
> > >
> > > to me, on each tool integration, there are key decision drivers:
> > > - importance of the tool on the market
> > > - interest of Maven devs to actually do integration maintenance
> > > - complexity of integration, technical prerequisites (with IDEs, for
> > > example, a dedicated independant project like m2e is necessary)
> > > - time factor: things evolve over time (e.g. 2 years ago, Docker was
> not
> > > what it is nowadays)
> > >
> > > any other key driver to document?
> > >
> > > once done, we'll discuss more precisely about the Docker integration
> case
> > >
> > > and probably finish with a vote :)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 20 octobre 2017, 11:30:49 CEST Robert Scholte a écrit :
> > >> Isn't this actually the same case as sdkman[1]?
> > >> Just wondering if we need to think about a general solution instead of
> > >> pulling everything into our project when possible.
> > >>
> > >> thanks,
> > >> Robert
> > >>
> > >> [1] http://markmail.org/message/oofvszmf56tbr7et
> > >>
> > >> On Thu, 19 Oct 2017 19:30:57 +0200, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > >>
> > >> wrote:
> > >> > great idea
> > >> >
> > >> > ok, we need a git repo at ASF
> > >> >
> > >> > what else?
> > >> > Is there some sort of release process? some sort of source to
> release?
> > >> >
> > >> > Regards,
> > >> >
> > >> > Hervé
> > >> >
> > >> > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit :
> > >> >> Thanks for the pointer, Carlos! I had searched the archives, but
> maybe
> > >> >> I
> > >> >> didn't go back far enough.
> > >> >>
> > >> >> I think moving these Dockerfiles into an ASF repo would be great
> for
> > >> >> their
> > >> >> maintainability.
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> Mike
> > >> >>
> > >> >> On 2017-10-19 03:50, Carlos Sanchez  wrote:
> > >> >> > Arnaud is correct, I sent an email to users@ back on Fri, Nov 7,
> > >> >>
> > >> >> 2014,>
> > >> >>
> > >> >> > 00:23 when I created the image>
> > >> >> >
> > >> >> >
> > >> >> > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier 
> > >> >> > wrote:>
> > >> >> >
> > >> >> > > These images are kindly managed by a PMC member of our project
> > >> >>
> > >> >> (Carlos)
> > >> >>
> > >> >> but>
> > >> >>
> > >> >> > > yes they aren't managed directly by the project>
> > >> >> > >
> > >> >> > > We can easily see with him to improve this IMO.>
> > >> >> > >
> > >> >> > > When he started that (several years ago) Docker wasn't what it
> is
> > >> >>
> > >> >> nowadays.>
> > >> >>
> > >> >> > > With docker being mainstream I agree that we can reconsider
> this.>
> > >> >> > >
> > >> >> > > The docker image build/distribution could perhaps be part of
> our
> > >> >>
> > >> >> release>
> > >> >>
> > >> >>

Re: Maven Docker Images

2017-10-21 Thread Hervé BOUTEMY 
ok, let's switch directly to the Docker case

I'm not a Docker expert, then I'm discovering things that my be obvious to 
others

IIUC Docker has an "officiel images" project [1] where Carlos provided a Maven 
image [2]: then this image is known as "the official Maven Docker image"
Carlos is an individual, he's also a PMC member of Maven

what do we want to say: the PMC member has provided an official Docker image or 
an individual has provided an official Docker image?

depending on the answer, some way of doing has to be changed (Git location or 
naming of the official image)

Regards,

Hervé

[1] https://github.com/docker-library/official-images

[2] https://github.com/docker-library/official-images/blob/master/library/maven

Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit :
> From my perspective it is just like sdkman including the conclusion. We have
> other tasks at our hands, maintaining a docker images is not something we
> should bother with. However needs one can easily create one and there will
> be thousands of variations different users want.
> 
> Let them create it on their own.
> 
> Manfred
> 
> Hervé BOUTEMY wrote on 2017-10-20 18:46:
> > true, from a general perspective, it's like sdkman
> > 
> > we need to discuss then decide if we want to maintain Maven Docker
> > integration (contrary to our current decision to not maintain Maven
> > sdkman integration but let sdkman community do it)
> > 
> > can we think about a general solution? perhaps not really a solution, but
> > a
> > decision process, yes
> > 
> > to me, on each tool integration, there are key decision drivers:
> > - importance of the tool on the market
> > - interest of Maven devs to actually do integration maintenance
> > - complexity of integration, technical prerequisites (with IDEs, for
> > example, a dedicated independant project like m2e is necessary)
> > - time factor: things evolve over time (e.g. 2 years ago, Docker was not
> > what it is nowadays)
> > 
> > any other key driver to document?
> > 
> > once done, we'll discuss more precisely about the Docker integration case
> > 
> > and probably finish with a vote :)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 20 octobre 2017, 11:30:49 CEST Robert Scholte a écrit :
> >> Isn't this actually the same case as sdkman[1]?
> >> Just wondering if we need to think about a general solution instead of
> >> pulling everything into our project when possible.
> >> 
> >> thanks,
> >> Robert
> >> 
> >> [1] http://markmail.org/message/oofvszmf56tbr7et
> >> 
> >> On Thu, 19 Oct 2017 19:30:57 +0200, Hervé BOUTEMY 
> >> 
> >> wrote:
> >> > great idea
> >> > 
> >> > ok, we need a git repo at ASF
> >> > 
> >> > what else?
> >> > Is there some sort of release process? some sort of source to release?
> >> > 
> >> > Regards,
> >> > 
> >> > Hervé
> >> > 
> >> > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit :
> >> >> Thanks for the pointer, Carlos! I had searched the archives, but maybe
> >> >> I
> >> >> didn't go back far enough.
> >> >> 
> >> >> I think moving these Dockerfiles into an ASF repo would be great for
> >> >> their
> >> >> maintainability.
> >> >> 
> >> >> Thanks,
> >> >> 
> >> >> Mike
> >> >> 
> >> >> On 2017-10-19 03:50, Carlos Sanchez  wrote:
> >> >> > Arnaud is correct, I sent an email to users@ back on Fri, Nov 7,
> >> >> 
> >> >> 2014,>
> >> >> 
> >> >> > 00:23 when I created the image>
> >> >> > 
> >> >> > 
> >> >> > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier 
> >> >> > wrote:>
> >> >> > 
> >> >> > > These images are kindly managed by a PMC member of our project
> >> >> 
> >> >> (Carlos)
> >> >> 
> >> >> but>
> >> >> 
> >> >> > > yes they aren't managed directly by the project>
> >> >> > > 
> >> >> > > We can easily see with him to improve this IMO.>
> >> >> > > 
> >> >> > > When he started that (several years ago) Docker wasn't what it is
> >> >> 
> >> >> nowadays.>
> >> >> 
> >> >> > > With docker being mainstream I agree that we can reconsider this.>
> >> >> > > 
> >> >> > > The docker image build/distribution could perhaps be part of our
> >> >> 
> >> >> release>
> >> >> 
> >> >> > > process.>
> >> >> > > 
> >> >> > > WDYT Carlos ?>
> >> >> > > 
> >> >> > > On Thu, Oct 19, 2017 at 4:16 AM, Mike Drob 
> >> >> 
> >> >> wrote:>
> >> >> 
> >> >> > > > I guess the natural follow-on question is whether the Maven
> >> >> 
> >> >> community>
> >> >> 
> >> >> > > > would consider publishing an official set of images? Or
> >> >> 
> >> >> alternatively>
> >> >> 
> >> >> > > > whether they should send a takedown notice to protect their
> >> >> > > > brand
> >> >> 
> >> >> and>
> >> >> 
> >> >> > > > trademarks...>
> >> >> > > > 
> >> >> > > > On 2017-10-18 18:36, "Manfred Moser" 
> >> >> 
> >> >> wrote:>
> >> >> 
> >> >> > > > > No. As you can see from the github URL this is NOT an apache
> >> >> 
> >> >> URL.>
> >> >> 
> >> >> > > > >