Transform dependencies just on publishing time

Help/Discuss
1

I am publishing subprojects project/a and project/b, where a depends on b

dependencies {
  implementation(project(:b))
}

Both subprojects group is com.example and version is 1.0
And I want a and b will be published as project-a and project-b
I.e. in maven I expect the following structure:

com\
  example\
    project-a\
      1.0\
    project-b\
      1.0\

I can reach it by setting artifactId as artifactId = "project-$artifactId"
But in project-a’s POM dependency on b looks like

<dependency>
  <groupId>com.example</groupId>
  <artifactId>b</artifactId>
  <version>1.0</version>
  <scope>runtime</scope>
</dependency>

when I expect <artifactId>project-b</artifactId>

Have tried to use

configurations.all {
  resolutionStrategy.dependencySubstitution {
    substitute(module("com.example:b:1.0")).using(module("com.example:project-b:1.0"))
  }
}

in couple with

versionMapping {
  allVariants {
    fromResolutionResult()
  }
}

but got error Could not find com.example::1.0

Is there way to apply dependency substitution, for example, just before from(components["java"]), so it will not affect project build tasks, but only publishing task?

2

Dependency substitution will never affect publishing actually.

The problem is more, that you try to set the artifact on the publication manually.
It has quite some drawbacks to do so and you should really avoid it.

If your main concern are the source directories should be a and b, not project-a and project-b, you could still do include(:project-a) in your settings script and then in the next line change the project directory of the project to be a. This way you do not need to manipulate the publishing artifact id.

3

Actually, I deveolp gradle settings plugin, which should add publishing possibility to any standalone library, just by applying this plugin in library’s settings.gradle.kts.
All the libraries are in corporate ecosystem, so the plugin should publish all the libraries in the same group (com.company.component). But usually libraries consist of subprojects with common names (core, backend, etc.).
So the idea is to publish each subproject as, for example, com.company.component:<library-name>-core:<version>, com.company.component:<library-name>-backend:<version>, and so on.
And, as I have noted, any requirement to library, other then applying plugin, should be avoided.

I agree with you that “manual” dependency control is bad practice, but have no see other way in my case.
Now I’m trying to use ComponentMetadataRule to change dependency record directly in publication metadata. Will report here when get some result.

4

You will not, also that does not influence publishing.

If you anyway develop a settings plugin, why do you not just follow my advice?
Include the subprojects with the name intended for publishing and set the project directory to whatever you want on disk.

5

You are right, ComponentMetadataRule is meaningless in my case.
As for renaming subprojects, it is not cool solution. Because primary idea of the plugin is to avoid any work on scripts, except applying the plugin. Also renaming require to edit subprojects interdependencies (i.e. project(":core") -> project(":mycomponent:core")).
All these changes seems simple alone, but are a lot of work all together :pensive:

I see the possibility to edit POM directly as XML in publising config. Though this looks like some kind of hack. And still need solution to change dependencies records in module metadata (.module jsons)

6

I see the possibility to edit POM directly as XML in publising config.

Yes, but you really shouldn’t do it, especially when also publishing GMM which you should.
There is no such customizing hack for GMM, short of adding a doLast action to the task that creates it and modify the file manually, because you are expected to properly model the build so that the correct / expected metadata is produced or there are other parts that will then not work properly as you also found out. And if the expected GMM is produced, you should also get the expected POM.

7

What about to create a copy of “java” component, modify dependencies in that copy and use it for publication?
But I’m not sure is it possible to modify SoftwareComponent dependencies.

8

Me neither.
And the idiomatic way indeed is to right away model your build properly. :slight_smile: