Add support for setting dockerFile and dockerFileDir via maven properties

[adrianluisgonzalez]

After upgrading to v0.15.1, I see the docker.assembly.dockerFileDir has been deprecated. It would be nice to retain support for configuring via properties.

In addition, when the BuildImageConfiguration is resolved from properties, the initAndValidate() method needs to be called in order for the dockerFileFile and dockerFileMode to be set (docker.assembly.dockerFileDir no longer works).

[rhuss]

Thanks a lot ! I tuned it a bit, but otherwise everythings fine.

Just out of curiosity: Why do you prefer property based configuration over XML style ?

[adrianluisgonzalez]

Great!

We tend to put all our project configuration in properties so it gives us just one place to look rather than multiple locations. I wouldn't say one is better than the other, but it allows greater consistency for how we work. For the same reason we prefer the external Dockerfile to make it more consistent with how we build our other docker images.

[adrianluisgonzalez]

@rhuss, I had a quick look at the integration branch and I noticed the following commit after merging this PR:
532529e

The change to src/main/java/io/fabric8/maven/docker/AbstractDockerMojo.java on line 247 removes the following:

resolved.initAndValidate(log);

This means BuildImageConfiguration.initDockerFileFile(Logger log) is not called on the configuration after the properties have been resolved so isDockerFileMode() remains false.

The unit test you added explicitly calls init:

 ImageConfiguration config = resolveExternalImageConfig(testData);
 config.initAndValidate(null);

Maybe I am missing something, or there a better place to trigger the init methods to run? I would have added the initAndValidate(log) call to the ImageConfiguration.Builder.build() method, but there isn't a log instance available.

Hope that makes sense.

[rhuss]

The critical point is this line which already does the resolution of the images before the validation. Hope this makes sense.

[adrianluisgonzalez]

@rhuss, thanks for the response. However, I believe there is still a problem.

Each time getImages() is called, new instances of resolved ImageConfiguration are created that have not had initAndValidate() called. Is the intention to keep the instances of resolved images so the same instances that are validated are used?

Something like this:

    private List<ImageConfiguration> resolveImages() {
        if (resolvedImages != null) {
            return resolvedImages;
        }
        List<ImageConfiguration> ret = new ArrayList<>();
        if (images != null) {
            for (ImageConfiguration image : images) {
                ret.addAll(imageConfigResolver.resolve(image, project.getProperties()));
            }
            verifyImageNames(ret);
        }
        return resolvedImages = ret;
    }

I have created a new PR #445

[rhuss]

Thanks, you are right, the resolved images should be cached.

I refactored the initial configuration handling quite a bit and pushed it to branch integration. Maybe you could have a look whether it works for you that way ?

[adrianluisgonzalez]

Thanks, the integration branch is working for me. Cheers!