Do not include partest and it's dependencies in generated pom.

[gkossakowski]

Define custom Ivy configuration that contains all dependencies of
partest (and partest itself) and make sure that this configuration
is not considered when pom is generated.

Remove the comment about significance of dependency order declaration.
Given the fact that we excluded conflicting, transitive dependencies
and all partest dependencies are isolated from regular dependencies
the situation is much better.

[gkossakowski]

Review by @adriaanm.

You can inspect generated pom by saying makePom which will print the path to the generated pom. Note, that partest dependency is not included there but junit (with proper scope) is.

[gkossakowski]

Also, since I'm invoking a bit more advanced sbt-tech, @harrah can you have a quick look?

[adriaanm]

To summarize, a dependency in the partest scope does not contribute any of its own dependencies to our compile scope.

[adriaanm]

LGTM

[adriaanm]

Hmmm... could you first compare this to @retronym's approach in scala/jenkins-scripts#36 (comment)?

[dragos]

It just occurred to me that there is no validation nor nightlies for modules. The IDE depends on them, especially since the move to use them as OSGi bundles, without repackaging. It's possible that a regression goes undetected until after a release. We're on thin ice!

[gkossakowski]

@adriaanm: yes, @retronym's approach disables consumption of transitive dependencies declared for partest. That affects only resolution within partest project. What I'm trying to fix is how we expose declared dependencies: I want to hide the fact that we depend on partest at least until we sort out dependencies of partest itself.

[harrah]

If the goal is what @adriaanm says: "To summarize, a dependency in the partest scope does not contribute any of its own dependencies to our compile scope.", I'm not sure why this pull request is necessary. If you declare something in test, it does not contribute to compile.

[gkossakowski]

I think @adriaanm misunderstood the purpose of this PR. The purpose of this PR was to not contribute partest dependency (and it's transitive dependencies) in any scope in all projects that depend on scala-xml. Does it make sense then?

[retronym]

I understand the benefit in hiding it from the classpath of recently added JUnit tests of this project.

But I agree with Mark, I don't see how an upstream projects could have been affected.

[gkossakowski]

@retronym: Sigh. I think I misunderstood how the test scope works. I thought if you depend on something in test scope then this dependency is transitively included in test scope of project that depend on you. I see here that I was wrong. I'll follow up with another PR which reverts this one.