Include test information in maven-publish poms

Help/Discuss
1

I have something like this

plugins { id("maven-publish") }

allprojects { apply(plugin = "maven-publish") }

gradle.projectsEvaluated {
  allprojects {
    val comps = project.getComponents().getNames()
    if ("java" in comps || "kotlin" in comps) {
      publishing {
        publications {
          try {
            create<MavenPublication>("maven") {
              versionMapping {
                usage("java-api") { fromResolutionOf("runtimeClasspath") }
                usage("java-runtime") { fromResolutionResult() }
              }
              // Note: we if/else here because a single publication cant have both
              // we pick Kotlin over Java if the project has any kotlin
              if ("kotlin" in comps) {
                from(components["kotlin"])
              } else if ("java" in comps) {
                from(components["java"])
              }
            }
          } catch (e: Exception) {

That I use to generate pom-default.xml files for my projects. These are missing all test information.
I checked the components set and there are no .*test.* components to add to a from(). I was trying to add a second create<MavenPublication>("maven-test") item to publish the test information.

Is there something simple I can do to resolve this? and either end up with maven-test/pom.xmls or have the test info in the main pom.xmls Im already generating. Thanks.

2

It’s highly discouraged bad practice what you do there.

  • do not use try-catch, but write your code in way it isn’t needed
  • do not use the legacy way of applying plugins with apply(...) but use the plugins { ... } block
  • do not check whether some component is available to do something dependent, but use pluginManager.withPlugin(...) { ... } to react to the plugin adding those components being applied, that will then also make the bad-practice projectsEvaluated { ... } obsolete
  • and most importantly, do not do cross-project configuration like with allproject { ... }, subprojects { ... }, project(...) { ... ] or similar, this introduces project coupling and works against some more sophisticated features and optimizations in Gradle

Especially for the latter part consider instead using convention plugins in buildSrc or an included build, for example implemented as precompiled script plugins.

3

But the question is about generating pom.xml for the test classes (or test artifacts).
Do you have any insight into how to do that?

4

Hm, strange, half the text I wrote is missing somehow.

Test files are by default something that is considered internal.
They are the tests that test your code.
If you want to share them, you could for example define a feature variant that is then published.

If it is more that you want to publish test utilities that your consumers can use in their tests,
I would not abuse the test source set though.

For that you can either create a separate project with different coordinates, or you can use the java-test-fixtures plugin which is exactly for that case an by default is published as feature variant.

5

Thanks! Im really just trying to dump state of resolved dependency information into some serialized files on disk. This is a large project that I am new to so any deep refactoring to support this effort is a non starter.

Are there any alternative methods for dumping the state which would include the source… and test information.

6

I’m not sure what exactly you mean with “source and test information”.
What exactly are you after?
Can you maybe build an MCVE where you can then tell which information you would expect how?

7

I’m not sure what exactly you mean with “source and test information”.
What exactly are you after?

Sorry… ambiguous language. I want some exportable / serialized file that shows each artifact, each dep in each artifact, and its full/resolved G:A:V for these deps.

I need to have this for the tests as well. ie atm I use maven-publish and get pom.xml for each jar in my project… But its missing all information. I want that test information as well.

I dont have to use maven-publish and pom.xml though. Anything parsable serialized format would be fine.

8

./gradlew dependencies?

9

Yeah I think I should have used that initially.
My initial deviation from using dependencies was due to the output format.
Its not impossible to parse, but I’d strongly prefer it to be in some other output format.

I saw others discussing here:

But it seems that there isnt first class support for this (could use community plugin though).

10

Yeah, they don’t want to maintain a stable format for programmatic consumption.
But you should easily be able to output an own format or use some community plugin that does it.