Document how workspace rules should interface with pom_file

[google]

Document how workspace rules should interface with pom_file

[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.