anchor.diff:  artifactory.mycompany.net/applications/myapp:0.0.1-SNAPSHOT-12345
   -------------------
   
  -(You can check this out with docker ps -a command). The "0.0.1-SNAPSHOT" part here simply comes from the <version> block in your pom.xml file, so it can be totally different in your case, of course.
  +(You can check this out with `docker ps -a command`). The `0.0.1-SNAPSHOT` part here simply comes from the version of your project (on top of your `pom.xml` file), so it can be totally different in your case, of course.
   
   To push this image to artifactory, we simply need to add a push command to the command line:
   
  
positive.code: 
  :hp-tags: Java, Docker, Maven, Spotify
  
  I have been working for 6 months in a new project in my company. It is quite exciting, we do a lot of cutting-edge technology and of course we use massively Jenkins for continous integration.
  
  One of the problems that we started facing at one point is *what* to deliver. We were used to publish our WAR artifact to Artifactory, where it layed there to gain dust. Then our integration-test framework would run immediately after the build (triggered by mvn integration-test), and instead of retrieving the artifact, would use a new build run to generate the WAR in the target/ dir.
  
  The test framework targets Amazon Web Services and from day1 we decided to have everything dockerized. So the deployment script would do the following:
  
  
negative.code: Strangely enough the email field is *mandatory* for the current version of the spotify Docker-maven-plugin to work correctly, so watch out!
  
  === Usage
  You can see that what I put in the pom.xml is parametrized by some automatic Maven variables (they look like `${something}`).
  There is a residual parameter which is `${myimage.build}` which in my case does not come from Maven internals, but from the command line: you can run the docker image generation like this:
  
  -------------------
  mvn docker:build -Dmyimage.build=12345
  