No BUILD files generated for a java dependency

[avibryant]

Using the following dependencies.yaml:

options:
  languages: [ "java", "scala:2.12.14" ]
  resolvers:
    - id: "geotoolkit"
      type: "default"
      url: https://maven.geotoolkit.org
    - id: "mavencentral"
      type: "default"
      url: https://repo.maven.apache.org/maven2/
    - id: "osgeo"
      type: "default"
      url: https://repo.osgeo.org/repository/release/

dependencies:
  org.geotools:
    gt-geotiff:
      lang: java
      version: "25.2"

update_dependencies.sh successfully resolves the packages and writes out workspace.bzl, but despite its claim to have written 92 BUILD files, there are none in 3rdparty.

[johnynek]

What update_dependencies.sh script do you have? I don't see one in the root anymore.

Also, to be clear, you aren't using the --disable-3rdparty-in-repo option which does not write the BUILDs and instead makes them a repo rule.

[johnynek]

okay, I see that update_dependencies.sh is in the published version.

Note that script does use the option I mentioned:

$BAZEL_DEPS_PATH generate -r $REPO_ROOT -s 3rdparty/workspace.bzl -d dependencies.yaml  --target-file 3rdparty/target_file.bzl --disable-3rdparty-in-repo
RET_CODE=$?

So, you can disable that, or use @third_party//...

I've never used this approach, but I think @ianoc prefers it. I guess it must write the targets in a bzl file somewhere so you can use that.

[ianoc]

@johnynek The reason we moved that one was.... in a low priority it was useful to compress any merge conflicts iirc to one file and not try write hundreds of them. But the real reason I made it was for a dependency resolution purpose, If the BUILD files are inline you need to have all of the export statements align fully between repos that might depend on each other.

E.g. if you have repos A, B. Where A depends on B.

in A if you depend on Foo, which depends on Bar from B. External dependency configuration could/was/is different between targets that depend on Bar from B, and those which do it from A. It comes up a bunch in terms of minor version changes (the transitive tree included in the generated files is different, causing runtime issues), exports not aligning, and if you do replacements they won't necessarily be respected. (We saw it with kryo amongst others).

Using the external repo avoids this since both A, and B use the same entry point via the 3rdparty dependency to start on the bazel deps tree and so it remains consistent.

[ianoc]

In our case at the time specifically we had

Repo's, A, B, C.

Where A depends on C and B depends on C

A, and B diverged on some dependency (hadoop 2 -> 3 transition i think actually at the time), without the external 3rdparty this was real tricky involving dummy dependencies injected and such.