Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circular dependency in boringssl-static/pom.xml #727

Open
trustin opened this issue May 6, 2022 · 6 comments
Open

Circular dependency in boringssl-static/pom.xml #727

trustin opened this issue May 6, 2022 · 6 comments
Labels

Comments

@trustin
Copy link
Member

trustin commented May 6, 2022

boringssl-static/pom.xml defines the dependencies that depend on themselves: https://github.com/netty/netty-tcnative/blob/netty-tcnative-parent-2.0.52.Final/boringssl-static/pom.xml#L731-L762

I guess the original intention of this dependency is to pull all native libraries for all platforms by just depending on netty-tcnative-boringssl, but it prevents a user from pulling a native library for only one platform by depending on something like netty-tcnative-boringssl:linux-x86_64. It also is a circular dependency which is maybe not desirable:

netty-tcnative-boringssl-static
|
+- netty-tcnative-boringssl-static:linux-x86_64 <---------+
   |                                                      |
   +- netty-tcnative-boringssl-static:windows-x86_64      |
      |                                                   |
      ...|                                                |
         +- netty-tcnative-boringssl-static:linux-x86_64 -+

I didn't look into other netty-tcnative-* POMs, but we'll also have to fix them if they have the same circular dependency.

@ejona86
Copy link
Member

ejona86 commented May 31, 2022

@trustin, is it correct to say you aren't using Maven? See #716 where we talk about Gradle and Bazel impacted by this. This is because of the classifiers; apparently classifiers are interpreted differently in other systems vs Maven.

@varming
Copy link

varming commented Aug 24, 2022

Looks like the Bazel issue was fixed in bazel-contrib/rules_jvm_external@d2c7811

@tkowalcz
Copy link

tkowalcz commented May 1, 2023

FWIW I have recently also encountered this in maven. For each platform we support I need to do this:

<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-tcnative-boringssl-static</artifactId>
  <version>2.0.60.Final</version>
  <classifier>osx-aarch_64</classifier>

  <exclusions>
    <exclusion>
      <groupId>io.netty</groupId>
      <artifactId>netty-tcnative-boringssl-static</artifactId>
    </exclusion>
  </exclusions>
</dependency>

@fangpenlin
Copy link

I ran into maven hanging problem, then ran a dependencies analytics and found the following circular dependencies diagram:

image

Not 100% sure that's the cause of our maven command hanging, still looking, but just FYI.

@trustin
Copy link
Member Author

trustin commented May 10, 2023

@trustin, is it correct to say you aren't using Maven? See #716 where we talk about Gradle and Bazel impacted by this. This is because of the classifiers; apparently classifiers are interpreted differently in other systems vs Maven.

Correct. It was Bazel at that time.

@conet
Copy link

conet commented Jul 19, 2023

The same happens with sbt I had a hard time to figure out why the native libraries from all platforms were pulled in although the classifier "linux-x86_64" was specified. Now I need to add an exclusion to solve this:

"io.netty" % "netty-tcnative-boringssl-static" % "2.0.61.Final" classifier "linux-x86_64" exclude("io.netty", "netty-tcnative-boringssl-static")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants