Is this a way to keep the original order for you? Or do you use this to order them only in the flattened pom?

This is a way to order only in the flattened pom

Not sure how necessary this is then. I would recommend keeping them in order in the original pom and flatten plugin could enforce the source ordering.
So on the other hand I wouldn't want too many parameters that bring only a little value, but then again it does bring some value.

So I checked and the order of dependencies matters for transitive dependencies. (https://stackoverflow.com/questions/31740785/why-order-of-maven-dependencies-matter/31743617#31743617)
This ordering might in these cases cause problems that are hard to debug.

So I would say that the order needs to stay the same. I think it already does even though I could not find a proper test for it (https://github.com/mojohaus/flatten-maven-plugin/tree/master/src/it/projects)

Because ordering can change the behaviour of the pom, I would not merge this.

@lasselindqvist The Maven resolution algorithm resolves transient dependencies' versions based on the root proximity of the pom.xml dependency tree. That's why the original pom should NEVER order dependencies, but when talking about flattened poms (which all dependencies are in the same level) the order doesn't really matter.

It uses the distance to decide the candidates, but if two transitive dependencies have the same distance, it takes the one that it first.
And the order does matter, because this plugin can and is used to deploy flattened poms to repositories and then used in other projects.

I am probably missing something, but how can you have transitive dependencies in a flattened pom? Anyway, feel free to close this PR and the issue if you think it doesn't make sense.

Thanks for the feedback!

http://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#flattenDependencyMode
flattenDependencyMode affects transitive dependencies differently
So the direct mode might for example just resolve the version numbers of direct dependencies from properties, but the "all" mode would bring new nodes to the visible tree in the file.
Then there is also the flattenMode, and in case of for example resolveCiFriendliesOnly, the dependencies might be left completely untouched.

Now, I don't want to reject it just yet, because it might make sense to merge it, have it off by default (as it is in the open PR) and have a clear warning in the documentation about the risk of using it.

I'd like to leave this issue open for a while to see if some third person has opinion or arguments for or against.