anchor.diff:  
   Talk to your network administrator for all the concerns about it. You can also experiment by creating a Docker registry on your local machine while waiting for the IT guys to answer (it usally takes some time :P ). More informations on the Docker registry can be found in the Docker guides.
   
  -Second big point is, what kind of disk space on Artifactory do you have and what bandwidth availability. A well built Docker image should not require much more than a WAR/JAR artifact takes in terms of size and upload speed, but  this requires some tuning.
  +Second big point is, what kind of disk space on Artifactory do you have and what bandwidth availability. A well built Docker image should not require much more than a WAR/JAR artifact takes in terms of size and upload speed, but some tuning may be needed. My suggestion: try, try and retry. Docker is not easy to understand at the beginning.
   
  +=== Efficiency in Docker images creation
   Long story short: the instruction order in your Dockerfile matters! Every line is a "layer" that Docker creates as basis for the next line, until you reach the end of the Dockerfile and the final image is done.
  +The Docker Registry you use is a smart service, and if it founds out that some layers that the Docker image you are pushing are already pre-existing in its own belly, it will move on to the next layer (a.k.a. the next line of the Dockerfile) directly. This means that you want to add the WAR/JAR object in the image creation as later as possible, so that a large portion of the final image is in common with other builds of your project. 
   
  -For my project, I use the official Jetty image from the Dockerhub onto which I then put my WAR, and produce a new image that I then upload to our private Artifactory.
  +For my project, I use the official Jetty image from the Docker Hub onto which I then put my WAR, and produce a new image that I then upload to our private Artifactory registry.
  +We achieved a delta factor between a new build and the previous build of about 31 Mbytes, whereas our WAR file weights about 26 Mbytes. Pretty neat!
   
   This is what my Dockerfile *would* be:
   
   -------------------
   FROM jetty:9.3.12-jre8
  -COPY mywarfile.war /opt/jetty/webapps/
  +COPY mywarfile-build12345.war /opt/jetty/webapps/   # this line differentiates the images one another
   ENTRYPOINT ["java", "-jar", "/opt/jetty/start.jar"]
   -------------------
   
  -You will see now how to produce the Docker image without needing any Dockerfile at all.
  +You will see now how to produce the Docker image without needing any Dockerfile at all using Spotify's Docker maven plugin.
   
   === Configuration
   Let's see how to configure the plugin in the project's `pom.xml`: 
  
positive.code: 
  I have been working for 6 months in a new Java/Maven 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:
  
  . build the WAR file again
  . copy it to the AWS target environment
  . on AWS, pull the Jetty base image
  . on AWS, package a new image
  . on AWS, spawn the container (together together with other ancillary services)
  
  This is clearly not very efficient. We have a lot of tools at our avaiablity (Artifactory in primis) but we are not able to make them work efficently.
  
  So I took myself the task to improve our workflow, thanks also to our DevOps specialist who explained me a lot of nuts'n'bolts of Docker.
  
  At one point it was clear that the best artifact to work with is not a WAR file, but a Docker image itself. I found out the wonderful *Docker-maven-plugin* by *Spotify* (check it out on https://github.com/spotify/docker-maven-plugin[their github repo]) to really suit my need. With it I can create and publish the Docker image of my app directly on Artifactory with a single Maven goal.
  
  === Prerequisites
  Your Artifactory should have been enabled to run as a "Docker Registry". This basically means that we are able to push and pull images to and from it. 
  
negative.code: 
  That's it. 
  
  If you use Jenkins CI like in my case, it is easy to inject the `${myimage.build}` value from the Jenkins built-in variable `$BUILD_NUMBER`, so every successful job run will automatically push a different image version on Artifactory. Or you could just forget about it and remove the versioning entirely, and only use the `latest` tag (this is automatically managed by the Docker-maven-plugin again). Your choice :)
  
  Have fun!
  