i have the following in my assembly descriptor (it's just the relevant snippet)

<fileSet>
  <directory>${project.build.scriptSourceDirectory}</directory>
  <outputDirectory>/</outputDirectory>
  <filtered>true</filtered>
  <includes>
    <include>startup.sh</include>
   </includes>
   <fileMode>755</fileMode>
</fileSet>

when my container gets built, the startup script doesn't have the correct permissions. i'm not sure if this something that should work in the context of this plugin or not.

i also tried setting the permission directly on the local filesystem to see if they carry over but was unsuccessful there as well. right now i'm working around this by specifying bash startup.sh as the command but that somewhat less then idea.

is this a bug? if not, do you have any suggestions on how this could be handled? i want this contained within the data container that gets built rather then mucking w/ the image that will be running it (which in this case is the 'official' tomcat instance).

TL;DR; it'd be nice to add strings like "docker.from", "docker.registry" to the build configuration class.
e.g. on all these @parameter values:
https://github.com/rhuss/docker-maven-plugin/blob/master/src/main/java/org/jolokia/docker/maven/config/BuildImageConfiguration.java#L15

Also allowing maven properties to be used to define env vars & ports would be nice using docker.env.NAME=value and docker.port.container.NAME=8080 as properties.

Rather long background on this....
So on the fabric8 project we're reusing your awesome maven plugin for generating & pushing docker images, we're also generating kubernetes json files too:
http://fabric8.io/v2/mavenPlugin.html#generating-the-json

then a parallel project called Jube which implements a pure kubernetes implementation without docker (for folks running java middleware on non-linux or non-docker based operating systems) - which makes docker-like images (which are just zips with shell scripts so can be run on any platform that has a JVM):
http://fabric8.io/jube/mavenPlugin.html#building-your-image-zip

we've found there's often lots of common stuff between these 3 maven plugins (docker / fabric8 / jube) for building images or generating kubernetes json. Things like the base image name, the image name, the env vars, the ports.

Using maven properties can help keep configuration DRY; since we can inherit stuff and put configuration into base projects (as its often folks have multiple images with the same base; or often expose similar ports or env vars).
e.g. this parent project defines a bunch of ActiveMQ stuff so defines the image name (based on maven aritfact) along with exposing the jolokia contianer port and defines the docker.baseImage.
https://github.com/jstrachan/quickstarts/blob/changes/apps/pom.xml#L38

(Note I'm just about to migrate all these from 0.9.x :)

So what would be nice is to be able to use maven properties to configure the build configuration.
e.g. on all these @parameter values:
https://github.com/rhuss/docker-maven-plugin/blob/master/src/main/java/org/jolokia/docker/maven/config/BuildImageConfiguration.java#L15

it'd be nice to have a name, like "docker.from", "docker.registry" so we can share configuration between parent/child poms - and share configuration between maven plugins too.

One thing we found with the generation of kubernetes json and jube image zips; things like env vars and ports tend to be additive; you often have base things and wish to add new ports; or override env vars etc. So again using maven properties turned out to be a nice way to do it. e.g. any pom.xml can expose an extra container port via adding

    <docker.port.container.jolokia>8778</docker.port.container.jolokia>

(BTW we used the '.container' suffix as kubernetes (and docker really) has the idea of internal container ports and external host ports; while the docker images don't yet allow you to specify the latter, certainly in kubernetes we can).

So for env vars and ports we found that just adding a little bit of code that if the user has not supplied a List/Map of ports/env vars, we look in the maven properties and build the list/map from those. e.g.

Here's the code:
https://github.com/jstrachan/fabric8/blob/changes/fabric8-maven-plugin/src/main/java/io/fabric8/maven/JsonMojo.java#L373-373

we're currently using "fabric8.env.FOO" as the naming convention; but I'd prefer it if we could all use "docker.env.FOO" really for all 3 maven plugins; then users can just configure things once in a nice DRY way.
e.g.
https://github.com/jstrachan/quickstarts/blob/changes/apps/fabric8-mq-autoscaler/pom.xml#L37-37

we use the same approach to defining labels in kubernetes json too; it works very nicely in maven as maven properties are much more composable.

I can supply a PR if you like; its really just adding a few strings to some @parameter values; and adding a factory method on the env vars / ports if there is nothing configured to look at the maven properties and create the List/Map from them. I figured I'd explain my thoughts first to see what you think

being able to provision a single WAR artifact as a ROOT.war would be a nice assemblyDescriptorRef value; I can see folks wanting to provision a single WAR into tomcat as a container.

I can supply a PR if you like?

Currently, only a name can be provided for push. Maybe it would be nice to allow multiple tags as well. Also, check, whether it makes sense to use a dedicated <registry> config option.

It should be possible to specify and start multiple containers during integration testing.

The timeout for contacting the docker server should be configurable

When starting a container it would be nice to be wait for a certain text pattern in the output to appear. Along with 'waitandwaitForHttpthe new configuration optionwaitForOutput` would add for fine control of the startup process.

I wonder if we should post process it in some ways to shrining or replace bad characters; or at least validate it up front so that the build fails immedately so that folks don't spend a while building an image that can never be pushed since the image name isn't valid to push to a repo?

i feel this is a bit different then issue #8, which is why i created a new one...

how do you feel about a docker:logs command that mimics docker logs? to start, it could perform the same default behavior as docker logs <container_id> and additional features could be added later.

i'm finding myself typing mvn docker:logs after running a mvn docker:start only to realize that won't work which is rather annoying. :)

PR on its way....

When using multiples containers (see #15) then it should be possible to link them together.

Data container created with an assembly are cleaned up automatically with stop, however, the image for this container still remains. We need an option/mechanism to get rid of this image as well.

having this in the readme would be super useful.

If an image has an <alias>, the container created during docker:start should be named with the alias. If already a container with name exists, then a suffix should be added until the name is unique. E.g. if the alias db is alread taken, try db_1, db_2, .... until a free name is found.

See #35 for a discussion about this.

Might be useful to remove temporary images/containers during building of an image. AFAIK there is a dedicated Docker API option for this in a recent API version.

so imagine you're working in development on an image that you wanna push to a registry so you can use it on multiple boxes (e.g. with kubernetes); so you might wanna use something like this...

    <docker.image>${env.DOCKER_REGISTRY}/mystuff/${project.artifactId}:${project.version}</docker.image>

then wherever your private docker registry is at $DOCKER_REGISTRY you're good to go.

However then at some point you might wanna release these images to the global registry. Now we could replace the $DOCKER_REGISTRY with registry.index.docker.io; however the common convention is to omit a registry prefix if its the global one in docker image names.

So we'd wanna switch from ${env.DOCKER_REGISTRY}/mystuff/${project.artifactId}:${project.version} to just mystuff/${project.artifactId}:${project.version} when doing a release.

So I'm wondering is it maybe cleaner to not specify the registry in the image name; but use docker.registry instead? Then if docker.registry is specified and its not the public registry, the mvn plugins would prefix the image name with it; then do things the usual docker way - otherwise it would be omitted?

To do this on the fabric8 quickstarts I had to hack this a bit with profiles ;)

e.g. I defined a docker.registryPrefix property:
https://github.com/fabric8io/quickstarts/blob/master/apps/pom.xml#L39

which defaults to "${env.DOCKER_REGISTRY}/" which I then add to the front of docker names.

Then I use a profile (docker-public) to override this in each build....
https://github.com/fabric8io/quickstarts/blob/master/apps/pom.xml#L117

it works but it'd be kinda nicer to just specify the docker.registry (maybe on the CLI) and for that to work and do the right thing in terms of image name (omitting it from the image name if its a public image, or appending it for non-public registries)

Add support for Fig and the successor Docker compositions via the new external configuration mechanism.

Instead of waiting a fixed amount of time when starting a container, there should be a possibility for pinging an URL or port. The plugin should wait until this is available or until a timeout has occurred.

I've seen a few folks trip up over this as right now it defaults to "http://localhost:2375" which will only work on linux. At least checking for DOCKER_HOST first will make it work well on Macs :)

it'd be nice if we just replaced "tcp://" with "http://" internally.

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build (default-cli) on project java-camel-cdi: Execution default-cli of goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build failed: java.net.MalformedURLException: unknown protocol: tcp
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build failed: java.net.MalformedURLException: unknown protocol: tcp
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 19 more
Caused by: java.lang.RuntimeException: java.net.MalformedURLException: unknown protocol: tcp
    at com.mashape.unirest.request.HttpRequest.getUrl(HttpRequest.java:104)
    at com.mashape.unirest.http.HttpClientHelper.prepareRequest(HttpClientHelper.java:164)
    at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:128)
    at com.mashape.unirest.request.BaseRequest.asString(BaseRequest.java:56)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.request(DockerAccessUnirest.java:321)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.hasImage(DockerAccessUnirest.java:72)
    at org.jolokia.docker.maven.AbstractDataImageSupportMojo.checkImage(AbstractDataImageSupportMojo.java:137)
    at org.jolokia.docker.maven.AbstractDataImageSupportMojo.createDataImage(AbstractDataImageSupportMojo.java:118)
    at org.jolokia.docker.maven.BuildMojo.executeInternal(BuildMojo.java:19)
    at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:78)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
    ... 20 more
Caused by: java.net.MalformedURLException: unknown protocol: tcp
    at java.net.URL.<init>(URL.java:592)
    at java.net.URL.<init>(URL.java:482)
    at java.net.URL.<init>(URL.java:431)
    at java.net.URI.toURL(URI.java:1096)
    at com.mashape.unirest.request.HttpRequest.parseUrl(HttpRequest.java:50)
    at com.mashape.unirest.request.HttpRequest.getUrl(HttpRequest.java:102)
    ... 30 more
[ERROR]

It should be possible to stream logging output to the console of the build during an integration test (using docker logs in some way)

i have all my application specific properties in an external file that gets pulled into the build via a filter for substitutions, etc - this lets me clean up the poms and keep build/application properties in separate places.

i'd like to be able to do this for properties i've defined in the docker maven config (eg bind ports, etc) and pull in the appropriate file based on the active profile.

it's possible this is already covered by the impending external configuration updates (i haven't looked at the code yet) but if it's not, i could see that being a big hit w/ that functionality.

thoughts? wiling to tackle this myself, just want to have a discussion first. :)

i'm trying to build a data volume for an nginx and based on the directions, i need to place content in the following two places

/usr/nginx/share/html
/etc/nginx

to do this i set my / and manage the output directories in the assembly.xml file. the problem is / is turned into a volume which makes the container unusable.

i'd like to propose the addition of a volumes element that takes an explicit list of volumes to expose and if this is tag has values, it overrides exposing exportDir as a volume.

thoughts?

While building, only when pulling an image (which takes some time) log output is printed. Instead it would be nice to have all build steps printed.

Probably in some grey color so that it doesnot get into the way (use advance ANSI here).

I.e. when pulling new images, a registry should be configurable

Currently the "raw" name of the warfile is in use, ie "myproject-1.0.0-SNAPSHOT.war", instead of the name specified in the build / finalName section of the pom.

as we build an image in a release, it'd be good to be able to also tag the base image too (if we can); so that if we wish we can rebuild a new version reusing the previous version.

So having a mvn goal to be able to pull and tag your base images first at the start of a release build; then using that exact version for the rest of the build would be great. Folks can then choose to either pull & retag; or reuse previous tagged base image versions.

This also avoids the base images changing during the build process; we can force a single pull per release build of each base image; they then get tagged and from then on we reuse the exact same image or all other images

Instead of being a pure flag, these variable should parse their content an use it as a list of image names to start / stop.

docker:stop doesn't seem to be stopping the container. running mvn w/ the '-X -e' flags shows it configuring the mojo but not executing any calls to the container afterwards.

Beside creating a plain data image on the fly which gets volume-linked into another container, it would be nice to support a mode where a base image (e.g. containing the app-server) and the created artefacrs are baked together to a single image which then can be pushed along.

It shouldn't be hard to extend the current approach:

• Make the base image more configurable
• Naming of the data image should be possible

It could be, that this is already possible ;-)

A way for getting artefacts and depdendency as files into a container should be provided. This should work also with indirect setups like boot2docker. If possible, this should work with docker means alone, without requiring support by the container in use.

Some thoughts on this:

• Use Docker Volumes (e.g. expose a directory below target to the container). However, this works only with a direct docker setup (i.e. running maven on linux) but not with indirect setups which uses a VM like Virtualbox for hosting the docker host. For that case one could think about getting the files into the the VM and share them from there. However this would break transparent usage of docker (i.e. one would need to know where one is) and probably needs support from the host VM.
• Pump over the artefacts/deps via scp. This would require a SSH setup in the container in use.
• Create an image via an internal Dockerfile on the fly, add artefacts/deps with ADD, build the image, create a container and link it to the container to start. This would still hold all the preconditions described above (works with indirect setups, no specific container setup required, etc ...), but it might be somewhat costly to create a temporary image only for getting files into a container.

None of the solution above is without drawbacks. What is your suggestion ? Is there any elegant way to accomplish this ?

Maybe the scp suggestion is the most lightweight solution and a container need to be 'maven aware' anyway if he wants to do something with the artefacts coming in (like putting them into a directory like webapps).

I'd like to be able to pass in variables when creating a docker image with "mvn docker:build".

PR on its way!

In order to avoid starting/stopping add an option docker.skip which prevents any docker related option.

As we now have a way for create data docker container, it would be nice to not use it only for linking this into the app-server container during integration testing but also to offer a possibility to push it to a registry so that it can be used as a deployment mechanism.

A new configuration option (like <env>) should be added to allow setting of environment variables when starting the container (similar to the -e option in docker run)

Especially for Micro Service which are build into a data image and started from there it would be nice to specify a defaul command as well. Currently the command from the base image is used (if any).

So I can totally do this...
http://fabric8.io/v2/mavenPlugin.html#example

mvn clean install docker:build
docker push $DOCKER_REGISTRY/mydemo/war-camel-servlet:2.0.0-SNAPSHOT

(or I can type docker push XXX and just copy/paste the image name from the output of the "mvn docker:build) and that works too.

but if I try "docker:push") I always get a failure:

mvn clean install docker:push -X
[ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:push (default-cli) on project fabric8-mq: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:push (default-cli) on project fabric8-mq: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:84)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 19 more
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.processChunkedResponse(DockerAccessUnirest.java:503)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.processPullOrPushResponse(DockerAccessUnirest.java:423)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.pullOrPushImage(DockerAccessUnirest.java:240)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.pushImage(DockerAccessUnirest.java:227)
    at org.jolokia.docker.maven.PushMojo.executeInternal(PushMojo.java:23)
    at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:82)
    ... 21 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]

I've not had chance to delve into whats wrong though

Hi again!

My project is making docker image using your plugin. This image is very simple and just contains a jar file and the command to run it. But the problem is that my jar file which were rpoduced by maven and it starts just fine, has different size than the one, copied to docker image. And the one in image cannot be started, image also cannot be run by docker because it says: Error: Invalid or corrupt jarfile maven/dlr-application-0.0.2-SNAPSHOT.jar

This is the size of copied to docker image jar:
-rw-rw-r-- 1 vagrant vagrant 35580429 Nov 18 17:17 dlr-application-0.0.2-SNAPSHOT.jar

And this is the size of the same jar, produced by maven:
-rw-rw-r-- 1 vagrant vagrant 20991343 Nov 18 17:17 dlr-application-0.0.2-SNAPSHOT.jar

so as you can see, first one which is copied by docker-maven-plugin is almost 2 times bigger and does not start.

Referencing docker issue moby/moby#8176
When stopping containers started during integration testing, the docker engine was returning a 500 error.

Tracing the error on my docker engine, I find the following:

Nov 24 09:11:52 integration2 docker: Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy
Nov 24 09:11:52 integration2 docker: [50c6bc48] -job delete(ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e) = ERR (1)
Nov 24 09:11:52 integration2 docker: [error] server.go:1062 Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy
Nov 24 09:11:52 integration2 docker: [error] server.go:91 HTTP Error: statusCode=500 Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy

I was able to replicate the same problem from the docker CLI by running:
docker run -d myimage/etc
wait for container to fully initialize.
docker stop ImgID;docker rm ImgId
results in the same error.

However, placing a pause into the operation allows the docker engine to complete the stop before the remove
docker stop ImgId; sleep 1000; docker rm ImgId works fine.

fig (http://www.fig.sh/) can manage development env easily. now docker-maven-plugin support "Starting and stopping Docker containers for integration testing and development". any idea to support " Starting and stopping Docker containers from fig.yml for integration testing and development"

sometimes folks wanna build stuff and push to the global registry; sometimes folks wanna push to a local registry. I wonder if the registry host should default to using an environment variable rather than a maven build property; as its kind of an environment thing?

e.g. I found we had to add these instructions to add a custom profile to ~/.m2/settings/xml to enable the 'default to env var' behaviour. I figured it might be nice to have this by default?
http://fabric8.io/v2/mavenPlugin.html#specifying-the-location-of-your-local-docker-registry

e.g. if a build is intended to use a private docker registry then maybe its better to get this from an environment variable?

I was getting quite confused trying to figure out why the push wasn't working. I kept getting the errors shown below.

Turns out adding -Ddocker.username=jolokia -Ddocker.password=jolokia to the CLI fixed it. (Thanks for figuring that out @iocanel!).

I wonder if the plugin could do a big warning if the system properties are not specified and a server id (of the registry host:port) is not available; so new users grok what they need to do.

e.g. if there's no authConfig values and no system properties for docker.username / docker.password and no ~/.m2/settings.xml we should fail the build and output a big warning telling folks to add an authConfig, set the system properties or add something like this to their ~/.m2/settings.xml:

       <server>
           <id>192.168.59.103:5000</id>
           <username>jolokia</username>
           <password>jolokia</password>
       </server>

then lots of users who just see this error will thank you ;)

INFO] --- docker-maven-plugin:0.9.12:build (default-cli) @ fabric8-mq ---
[INFO] Copying files to /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker/maven
[INFO] Building tar: /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker-tmp/docker-build.tar
[INFO] DOCKER> Created data image 192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT
[INFO]
[INFO] --- docker-maven-plugin:0.9.12:push (default-cli) @ fabric8-mq ---
[INFO] Copying files to /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker/maven
[INFO] Building tar: /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker-tmp/docker-build.tar
[INFO] DOCKER> Created data image 192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT
[WARNING] DOCKER> Couldn't parse answer chunk 'EOF
': org.json.JSONException: A JSONObject text must begin with '{' at 1 [character 2 line 1]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.221s
[INFO] Finished at: Wed Nov 12 14:59:41 GMT 2014
[INFO] Final Memory: 39M/366M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.9.12:push (default-cli) on project fabric8-mq: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.12:push (default-cli) on project fabric8-mq: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:87)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 19 more
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.processChunkedResponse(DockerAccessUnirest.java:547)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.processPullOrPushResponse(DockerAccessUnirest.java:467)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.pullOrPushImage(DockerAccessUnirest.java:264)
    at org.jolokia.docker.maven.access.DockerAccessUnirest.pushImage(DockerAccessUnirest.java:251)
    at org.jolokia.docker.maven.PushMojo.executeInternal(PushMojo.java:23)
    at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:85)
    ... 21 more
[ERROR]

Hi guys!

I am using your docker-maven-plugin. I configured docker to run on vagrant box and my application to create docker image and push it into a custom registry. The problem is that locally everything works just fine, but when I try to do the same using Jenkins job with the same maven version, settings and the same java version, it gives an error: [ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.10.4:build (default-cli) on project dlr-parent: Unable to parse configuration of mojo org.jolokia:docker-maven-plugin:0.10.4:build: Error loading class 'org.jolokia.docker.maven.Image'

I have no any idea what can be wrong.

doing so would allow me to maintain a single assembly descriptor for a project when i am also creating a zip export.

it doesn't need to do anything else but function as a symbolic name (based upon the description of it's usage in the maven docs).

Similar to https://github.com/spotify/docker-maven-plugin it should be possible to further tune the parameters for building the data image:

• Allow a Dockerfile
• Entry Point

BTW, @rculbertson, wouldn't it be an option to merge efforts ? I.e. one of the highlights of this plugin is to use a plain maven-assembly-plugin decscriptor for creating the data container (which is much more flexible than including files via path only).

i need to bind/export volumes as mount points when a container starts up. this would allow a workaround for containers that do not do this already do this (eg. the 'official' docker tomcat container).

i was going to suggest just adding a child element to volumes but perhaps that would be confusing, so maybe exports instead? eg:

<exports>
  <export>/path/in/container</export>
  <export>/path/in/host:/path/in/container</export>
</exports>

let me know thoughts, i have an immediate need for this and can spend some time on it in the coming days (followed by the naming issue as that's now 2nd on my list).

We are using a wildfly base image with an applied patch. The Dockerfile is

# Use the wildfly-8.1.0.Final image
FROM tdiesler/wildfly:8.1.0.Final

MAINTAINER Thomas Diesler <[email protected]>

# [TODO] Why does this not work?
# ADD wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /opt/jboss/wildfly

# Copy & Extract the WildFly Camel patch
COPY wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /tmp/wildfly-camel-patch.tar.gz
RUN tar -xzf /tmp/wildfly-camel-patch.tar.gz -C /opt/jboss/wildfly 

# Set the default command to run on boot
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone-camel.xml", "-b", "0.0.0.0"]

It seems that I cannot apply a patch with the docker-maven-plugin because it replaces /opt/jboss/wildfly and does not add to it.

To reproduce, please build

https://github.com/tdiesler/wildfly-camel/tree/docker-mvn-plugin

In docker/pom.xml I commented out the wanted target config

Authentication against the docker daemon should be possible.

If an image is specified without a tag, autoPulling works a bit weird currently:

• If an image with any tag is present, then no autoPull happens
• If there is no image locally tagged latest but another image with another tag is there then an error occurs
• If no image is locally available, then all images (with all tags) are pulled.

I would like it to work like that if no tag is specified:

• Check if there is a image with tag latest locally.
• If not, try to pull with tag latest.
• If no such image exists remotely, check the local images and take the one with the highest version number (considering versioning sticks to semantic versioning
• Fail.

why not just treat these as a list (same way as a maven configuration) so the various forms for mappings are supported?

docker.maven.ports.1 = 5678:8080
docker.maven.ports.2 = 0.0.0.0:80:80
docker.maven.ports.3 = host.port:22

i stumbled across this working on pull request #60.