Document how workspace rules should interface with pom_file

[deadmoose]

My skylark's pretty rusty after a year on the outside, but if I'm following correctly:

The pom_file rule crawls the targets' dependencies, using the maven_coordinates=[XXX] tag to identify things that came from maven & can/should be included in {generated_bzl_deps}

That works fine for the deps coming from here since workspace_defs.bzl is turning maven artifact strings into java_import_external rules w/ that tag added.

But anything defined as a native maven_jar is missed; it's got that artifactid directly on it, but not as that particular tag. And despite the claim here that all rules support tags, maven_jar doesn't appear to support them, so I can't even just tack it on.

I'm using bazel-deps to generate all the rules, so it looks like I could potentially hack that to stick the tags on the java_library rules it tosses under third_party, but it feels like if I knew what I was doing, it shouldn't be too bad to automagically get that off the underlying maven_jar rule.

[ronshapiro]

Unfortuantely, I haven't seen any mechanism by which pom_file could read information from maven_jar as it currently stands. Patching maven_jar to include a tags attribute sounds like a great option, and then bazel-deps can use that. Or maybe even maven_jar should just specify the tag automagically.

Alternatively/additionally, bazel-deps could probably use java_import_external which has better reliability during builds /cc: @jart @johnynek

[deadmoose]

Or maybe even maven_jar should just specify the tag automagically.

Other than the red tape involved to nail down the officially supported tag, yes. Otherwise future people are going to have the same confusion I had where I added this into an existing project & then stared blankly when it didn't do anything. (I should probably file another bug/just make a PR with a bit more documentation around that requirement, but it'd still be better for the obvious things to Just Work[tm])

Alternatively/additionally, bazel-deps could probably use java_import_external which has better reliability during builds

Skimming the docs, it looks like that's inadequate for private use: maven_jar is maven aware and can hit my settings.xml to figure out about credentials to hit our internal repository, but java_import_external seems to want URLs that are expected to just work.

I might be able to get bazel to interpolate in something pulled in from elsewhere, but I'd also be nervous that something somewhere would naively dump https://blah:[email protected]/ to a log.

[deadmoose]

Looks like I'm unblocked for the moment with minimal pain by hacking bazel-deps to add the tag to the java_library wrappers it generates around the maven_jars.

🤞

[ronshapiro]

I'm not sure what the best practice is (or if there is one) with regard to bazel+internal maven servers+credentials. That sounds like a way that builds become unreproducible?

Looks like I'm unblocked for the moment with minimal pain by hacking bazel-deps to add the tag to the java_library wrappers it generates around the maven_jars.

That also works :)

Shall we close this issue?

[deadmoose]

I'm not sure what the best practice is (or if there is one) with regard to bazel+internal maven servers+credentials. That sounds like a way that builds become unreproducible?

Why? It's still a maven repository with immutable published artifacts and my WORKSPACE files can list expected checksums for them, etc. They just aren't publicly available and/or available by virtue of just being on. some private network. Try to hit it as some random person & it'll fail downloads and bazel will break just like if you hit a public repo and all your mirrors barfed at the same time.

Shall we close this issue?

I can open another issue/PR for documenting "Hey, if you want to use this, you need to do this extra legwork", but it's really unfortunate if that's the answer when maven_jar is a first-party rule in bazel and theoretically should let this all happen automagically.

[jart]

I would recommend using java_import_external which is in the bazel codebase and documents itself as the recommended practice. Please note it does not grab transitive dependencies automatically. You can use Bazel Maven Config Generator to crawl POM metadata and generate a WORKSPACE config that's fast, reliable, and mirrors artifacts to Google Drive. See demo video and best practices guide.