fix(SHRINKRES-299): Support "Maven CI Friendly Versions"

[famod]

by preferring the output of flatten-maven-plugin over the regular pom.xml
which just has a "useless" placeholder like ${revision} as the version.

Some notes about this approach:

There is already a TODO note in ClasspathWorkspaceReader.createFoundArtifact(File) about whether it would be better to load the pom (and its parents) "properly" via Maven.
This might have also been a possible solution, but I am not sure whether such a heavy lifting should be done there.
The note regarding "cycle in graph reconstruction" also scared me off a bit, to be honest.
Furthermore, a revision property does not need to be defined in the pom at all (AFAIK). It can also be passed in via -Drevision=.... Parsing the entire Maven model would not help in that case.

My first approach was to completely swap the FileInfo:

    private FileInfo createPomFileInfo(final File childFile) {

        // assuming that directory entry on classpath is target/classes directory, we need
        // to go two directories up in the structure and grab a pom.xml file from there
        // SHRINKRES-299: we prefer a "flattened" pom.xml written by flatten-maven-plugin
        File parent = childFile.getParentFile();
        if (parent != null) {
            parent = parent.getParentFile();
            if (parent != null) {
                FileInfo fileInfo = new FileInfo(new File(parent, flattenedPomPath));
                if (!fileInfo.isFile()) {
                    fileInfo = new FileInfo(new File(parent, "pom.xml"));
                }
                return fileInfo;
            }
        }

        return null;
    }

but this caused problems in MavenResolvedArtifactImpl.artifactToFile(Artifact) as the name of the artifact file would then not be pom.xml anymore but .flattened-pom.xml or something else. I would have needed to re-evaluate the new system property there. Or maybe org.eclipse.aether.artifact.Artifact.getProperty(String, String) could have been used (ClasspathWorkspaceReader might be able to set a property that signals "this artifact is a pom!").
I dropped that approach because it did not feel right.

And why did I introduce a new system property?
The name and the output directory of the flattened pom are completely configurable, see: https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#flattenedPomFilename
Also there's a ticket about changing the default output folder/name: mojohaus/flatten-maven-plugin#53
So, with the system property people can adapt shrinkwrap-resolver to their flatten config.

[famod]

@bartoszmajsak I'll try to implement a test for this but as of now there is (apparently) no in-depth test for this class, only a "shallow" one testing dangling directories (ClassPathScanningTestCase.classpathWithDanglingDirs()).

[famod]

Test implemented. Actually I am pretty pleased with the outcome.

[famod]

This should be it, now. I had to fix a test failure by adding a normally ignored file and some typos.

[famod]

@bartoszmajsak Ready when you are! :-)

[bartoszmajsak]

@bartoszmajsak Ready when you are! :-)

On it :)

[bartoszmajsak]

Many thanks for that improvement @famod. Just one thing I wanted to get your input for. See below :)

[famod]

Ah, shoot! That dependency was already available. Will fix that...

[famod]

Ah, shoot! That dependency was already available. Will fix that...

Done. I decided to add the dependency to the root dependencyManagement since it is used in two modules now.

[famod]

Well, that's strange. DistributionStageImplTestCase fails with system-rules >= 1.18.0 because it finds multiple matches (but only with JDK7!):

This second line is not there with system-rules <= 1.17.0 (and generally with JDK8!).

I will stop investigating at this point because it's out of scope for this PR.

@bartoszmajsak Do you want me to squash anything? If not I'm done (literally).

[bartoszmajsak]

Thanks! I think we are good at locking it down to 1.17.0 for the time being, but it would be great to chase that up upstream.

[famod]

@bartoszmajsak Thanks for merging. Are you still planning to cut a relase this year?

[bartoszmajsak]

@bartoszmajsak Thanks for merging. Are you still planning to cut a relase this year?

@famod It's been released. I will push to master with the tag as soon as it lands in maven central. Again, many thanks for bringing it back to life :)