dependencyManagement section in the generated POM.xml contains entries from unrelated configuration?

[dweiss]

I see entries in dependencyManagement section of my project which are only declared (transitively) in a configuration that is used internally within the build file - it is not explicitly extended or attached to any java plugin's configuration.

Is there any trick to get rid of these entries? They don't show up as dependencies - only in dependencyManagement, but they pollute the output POM file.

[dweiss]

@dansanduleac I'm sure you have an idea off the top of your head - could you enlighten me about what to do with this? Look at templateProcessor configuration in this file - the dependencies declared there shouldn't propagate to the generated maven POM (but they do - to the dependencyManagement section).

https://github.com/carrotsearch/hppc/blob/master/hppc/build.gradle

[Jacks0N23]

I have the same issue, did you solve it?

[dweiss]

See here.
https://github.com/carrot2/carrot2/blob/master/gradle/maven/defaults-maven.gradle#L86-L98

[dansanduleac]

Sorry I didn't see this.
GCV will configure every java project in your build, unless you tell it to skip a project.
This includes

1. enforcing locks on that project
2. bubbling up the project's dependencies into :unifiedClasspath, the configuration that collects all dependencies, and which is ultimately written to the lock file and to every POM's dependencyManagement

You can disable this behaviour in a particular project by running disableJavaPluginDefaults()

It used to be the case that the dependencyManagement section would only list the transitive dependencies of the project that generated the POM, but it got reverted in #504 because gradle lazy structures are tricky to wire up correctly, and it blocked another workflow.

As explained in that PR (see below), these extra dependency constraints should have no real effect on the POMs. But if you want to make the POM cleaner, then you can exclude that internal project from GCV.

When publishing maven POM files though, this filtering doesn't make a difference, because constraints in that don't correspond to a real dependency in that component's downstream subtree will be ignored anyway (couldn't find a link but this is my observed behaviour of maven resolution, and specifically gradle's implementation of it).

[Jacks0N23]

I was wrong, i found a little bit different bug. Here is part of my .module file

"variants": [
    {
      "name": "releaseApiPublication",
      "attributes": {
        "org.gradle.category": "library",
        "org.gradle.dependency.bundling": "external",
        "org.gradle.libraryelements": "aar",
        "org.gradle.usage": "java-api"
      },
      "dependencies": [
        {
          "group": "",
          "module": "675f1a80b1e84a10",
          "version": {
            "requires": "unspecified"
          },
          "excludes": [
            {
              "group": "org.hamcrest",
              "module": "hamcrest-core"
            },
            {
              "group": "org.hamcrest",
              "module": "hamcrest-integration"
            },
            {
              "group": "org.hamcrest",
              "module": "hamcrest-library"
            }
          ],
          "attributes": {
            "org.gradle.usage": "consistent-versions-usage"
          },
          "requestedCapabilities": [
            {
              "group": "gcv",
              "name": "versions-props",
              "version": "0"
            }
          ]
        },

As you can see first group is empty and when I try to use this external module in another project it fails, because gradle cannot parse this .module file.
It started when I migrate to GCV plugin

Could I just delete first group? Could you help me how to do it?

[dweiss]

As explained in that PR (see below), these extra dependency constraints should have no real effect on the POMs.

Unfortunately listing all dependencies in dependencyManagement does have an inpact on consumers - it broke the build in downstream projects for me (I'd have to dig up the details though, it was a while ago).

[dansanduleac]

@dweiss that's surprising, if what you said is indeed the case (that this dependency is "only declared (transitively) in a configuration that is used internally within the build file").
From what I've seen, gradle and maven consumers treat a POM's dependencyManagement as constraints that apply only within the subtree of that POM.

So if we have (-> means a dependency, the dependencyManagement section being part of a:1's POM):

root -> a:1                      -> b:1 -> c:1
          dependencyManagement
            c:2
            f:2
     -> f:1

then you should get

a:1
b:1
c:2
f:1 (not f:2)

@Jacks0N23 you should file a separate issue.
Off the top of my head it looks like you're depending on an internal project that's unconfigured (doesn't have a version nor a group).

[dweiss]

Surprising is our craft's other name, isn't it... I'll get back to you once I come across this again (it's been a while and I don't have the time to backtrack). I'm sure it'll happen sooner or later.

[AlexLandau]

I just ran into a case where this is an issue.

We have repos A and B, where B contains plugins for a "client" module from A. These plugins will be run in an environment where the client and its dependencies are provided, so we'd like these dependencies to be the exact versions used by A. We accomplish this by declaring an enforcedPlatform dependency on the client module.

B already uses GCV, and we are working on getting A to use GCV. When GCV in A is turned on, B (when picking up the new client version) downgrades a variety of dependencies not used by the client module due to this changed behavior. This causes two problems: Currently, this causes multiple conflicts where B can't find versions that satisfy all requirements (even after --write-locks is run); and, longer-term, it will unnecessarily constrain versions of dependencies unrelated to the client.

We could switch to use platform vs. enforcedPlatform to avoid these conflicts, but that adds the risk of compiling and/or testing against the wrong versions of third-party libraries.

(Side note: We happen to be using enforcedPlatform on the client module's POM directly vs. using the Gradle platform plugin as recommended. However, the extra dependency constraints appear both in the .pom file and the .module file, so this should be irrelevant.)

[dweiss]

If I remember correctly it was indeed version constraints that caused my headaches too.