What happens is that the talend-component-plugin resolves the jars, then tries to find the associated cars and then extracts the jar from the car.

The issue is that if the cars are not added as dependencies in the pom, then:

• the first time, the plugin will notice that the car is not there and resolve it, which will result in a download from Maven
• then next time it'll find a car with the right X.Y.Z-SNAPSHOT in the local repository and believe it's the real deal. The issue is that if in the meantime a new version of the snapshot has been pushed to Nexus, the pom resolution will fetch the new jar but not the new car and the plugin resolution will believe it has the last car when in fact it has an old one. Since we then proceed to get the jar from the car, the jar is out-dated 

When trying to build a cloud-components docker's connectors image in snapshot the latest snapshot car may not be taken by the mojo process.
This may happen if the m2 repository is not cleaned before executing goal and the wanted car artifact already exists in the snapshot version in repository.
Thus, we can build an obsolete and non deterministic repository.
The issue is coming from here. If the artifact already exists in repository, the maven resolving is not done. Thus, snapshot may not be up to date!

First solving approach:
We should call directly the resolve method. Which uses maven-resolver-api:

Resolves the path for an artifact. The artifact will be downloaded to the local repository if necessary. An artifact that is already resolved will be skipped and is not re-resolved. In general, callers must not assume any relationship between an artifact's resolved filename and its coordinates. Note that this method assumes that any relocations have already been processed.

What was done:

The whole logic behind the mojo prepare-repository seems to be built on the premise that the single source of truth is the car. It makes no sense to find the jar, assume there's an associated car without checking it's in the dependencies and then get the jar from the car.

The code of the mojo is rather complex, I re-wrote it since it's used in a single place and we can easily test that it works.

• The new mojo searches for car dependencies in the dependencies of the talend-maven-plugin instead of the dependencies of the project (which makes sense since they are used by the plugin). It searches for the cars only, and with compile scope, the test scope was a hack.
• The ImageM2Mojo was not used anymore, I removed it.
• Also, I started extracting constants such as the car extension.
• Finally, I started documenting things so it's easier to maintain.