gnodet commented on PR #13066: URL: https://github.com/apache/maven/pull/13066#issuecomment-5574512413
Thanks for the PR — this addresses a long-standing gap (21 years, 71 votes, 5 duplicates). **On the direction:** I think this is the right approach. The core insight is that a `test-jar` is not "private tests" — it's an explicitly published artifact with its own classpath contract. The moment you configure `maven-jar-plugin` with `<goal>test-jar</goal>`, you're making a deliberate decision to package test classes as a reusable, deployable artifact with its own GAV coordinates. At that point, its test-scoped dependencies are part of that contract, and stripping them produces a broken classpath for consumers. The counter-argument that "tests are not public" only holds when there *is* no test-jar. If you don't want test code to be reusable, you simply don't create one. But once you do, the current behavior is the worst of both worlds: Maven lets you publish the artifact but silently drops the dependencies it needs to function, forcing every consumer to manually reduplicate them. The approach here — a narrowly-scoped, Maven-4-only decorator that only allows direct test-scoped children through when resolving a `test-jar` node — is appropriately conservative. It doesn't make test scope generally transitive, it doesn't affect regular JAR resolution, and it preserves Maven 3 personality behavior. **A few things to address before this can move forward:** 1. **Unit tests for `TestJarDependencySelector`** — the IT coverage is solid, but the selector itself should have direct unit tests covering edge cases (nested test-jars, test-jar with transitive test-jar dependencies, interaction with exclusions/optional). 2. **Type detection** — the selector keys on `ArtifactProperties.TYPE` being exactly `"test-jar"`. Worth verifying this property is reliably set on artifacts resolved from the repository, not just in-reactor. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
