An example of how a class would look like:

import org.jboss.shrinkwrap.api.GenericArchive;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.StringAsset;
import org.jboss.shrinkwrap.descriptor.api.Descriptors;
import org.jboss.shrinkwrap.descriptor.api.docker.DockerDescriptor;

public class DockerIdea {


    @WithFixture
    public static GenericArchive createFixture() {
        DockerDescriptor descriptor = Descriptors.create(DockerDescriptor.class)
                        .from("ubuntu")
                        .run("apt-get update", "apt-get install -y openssh-server", "mkdir -p /var/run/sshd")
                        .run("useradd test -d /home/test", "mkdir -p /home/test/.ssh")
                        .entrypoint("/usr/sbin/sshd", "-D", "-e");

        return ShrinkWrap.create(GenericArchive.class, "sshd")
                .add(new StringAsset(descriptor.exportAsString()), "dockerfile");
    }

}

Notice that now the fixture class is compact as it contains all the information it requires in a single source.

What is the point of this? Everyone knows (or should learn) Dockerfile syntax. The existing system works fine IMO.

Well there is one use case which would be better. If you see on SSHD example in https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer/Dockerfile the keys are hardcoded directly, but in the test https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshdContainer.java are get directly from the test folder where the keys where generated. Of course you can do what is done here of copying paste the keys, but this is in my opinion not the best way since you may have failures of test because of any change of keys, but not changing them in Dockerfile.

It is the fixture, not the test, which defines the private keys.

In this case it is probably a simple mistake that the Dockerfile redundandly hardcodes the public keys, rather than loading them from the resources directory where they are already defined:

COPY unsafe.pub unsafe_enc_key.pub /tmp/
RUN cat /tmp/*.pub > /home/test/.ssh/authorized_keys

With that fixed, there is not much real chance of mistakes when working on the fixture, since the public and private keys are all plainly grouped in one source directory.

Also an advantage of the existing system is that you can work on the Dockerfile (and/or its associated resource files) without even running acceptance tests, just by using docker build -t testing src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/Whatever && docker run -ti testing /bin/bash. Since the tests can take several minutes apiece to run, this is a much more pleasant way to play with minor modifications to the container before you check your work in the actual test. I recall doing that for XvncSlaveContainer: before trying to run Jenkins and its XVNC plugin against the server, I first needed to do a lot of experimentation to get permissions and the like right, and these could be simulated just by running the container, logging in as the Jenkins user, and checking if xmessage or the like ran without errors.

In any case I wanted to remove the other way, simply I wanted to add more features.

I am closing this with as something we will not implement.