incompatible_disallow_resource_jars

[comius]

Flag: --incompatible_disallow_resource_jars
Available since: 2018-11-12
Flipped in: Bazel 5.0.0
Will be removed: after 5.0.0

Migration

Disables the resource_jars attribute on java_library; use java_import and deps or runtime_deps instead.

For example:

java_import(
  name = "resources",
  jars = ["resource.jar"],
)

java_library(
  name = "lib",
  runtime_deps = [":resources"],
)

Unflipping

Use:

--noincompatible_disallow_resource_jars --experimental_builtins_injection_override=-java_library,-java_plugin 

The flag is correlated with Starlark java_library. In order to flip it back, also implementation of java_library and java_plugin need to be flipped back to native implementation.

[jkugler]

Can someone point me to the documentation on how one should modify their bazel rules to use the new syntax?

[cheister]

Using a java_import for the resource jar and adding the java_import to the deps or runtimes_deps does not include the contents of the resource jar in the jar created by the java_library.

Is there still a way to include a jar of resources in the java_libary jar without resource_jars?

[comius]

Using a java_import for the resource jar and adding the java_import to the deps or runtimes_deps does not include the contents of the resource jar in the jar created by the java_library.

This is true. However the jar file is on either compile or runtime classpath. So it is accessible from the java_library's implementation.

Is there still a way to include a jar of resources in the java_libary jar without resource_jars?

Is there a use case where the resources need to be in that particular java_library jar?

[jdai8]

Removing this from java_plugin rules is problematic since they don't have a runtime_deps attribute (not sure why).

We can use deps instead. Is this the intended workaround?

[eustas]

Is there a use case where the resources need to be in that particular java_library jar?

Yes. LICENSE file.

[comius]

Removing this from java_plugin rules is problematic since they don't have a runtime_deps attribute (not sure why).

We can use deps instead. Is this the intended workaround?

Using deps is ok - resources will be in this case on both compilation and runtime classpaths.

Is there a use case where the resources need to be in that particular java_library jar?

Yes. LICENSE file.

If you use java_library's resources attribute, the LICENSE file will be part of the library's jar.

[eustas]

Alas, resources have quite a weird path resolution rules.

[kpitt]

Alas, resources have quite a weird path resolution rules.

I also struggled for quite awhile trying to get resources files to have the correct path in the jar. Here's what I finally came up with for eliminating extra path components:

java_library(
    ...
    resources = ["LICENSE"],
    resource_strip_prefix = package_name(),
    ...
)

This will cause the LICENSE file to appear at the top-level of the jar contents.

That said, I still haven't figured out how best to deal with resource files that are produced by a generator rule without using resource_jars. A generated resources jar in runtime_deps gets merged into the *_deploy.jar for a java_binary rule, but so do all of the transitive third-party dependencies. That doesn't work if I'm trying to build a library that will be published to Maven, even if I wrapped the library in a java_binary rule with create_executable = False.

Interestingly, the recently refreshed online Bazel docs at https://bazel.build/reference/be/java#java_library still list resource_jars as a valid argument for the java_library rule, with no mention of deprecation or migration.

[comius]

Thanks @kpitt for a workaround.

I updated the resource_jars attribute documentation, to avoid confusion.

[pierventre]

Hi all, what was the reason behind the removal of resource_jars ? Sorry for the silly question, I am relatively new to the project. Also I tried to unflip the behaviour with:

--noincompatible_disallow_resource_jars --experimental_builtins_injection_override=-java_library,-java_plugin 

but it looks like the options are not recognized by test . Is this expected ?

[ghost]

Using a java_import for the resource jar and adding the java_import to the deps or runtimes_deps does not include the contents of the resource jar in the jar created by the java_library.

This is true. However the jar file is on either compile or runtime classpath. So it is accessible from the java_library's implementation.

One problem here is that this assumes that the Bazel user has bought into the Google/Blaze deployment model. My org ported a small constellation of Java projects from Maven to Bazel, but for compatibility reasons we retained our Maven artifact structure (i.e. we're not using java_binary's deploy jars). Where we can, we use resources and resource_strip_prefix to inject resources into jars, but we've also had to resort to aggregating resources into one or more jars (really .zip(s)) and then injecting via resource_jars. (The latter is especially common when aggregating resources from disparate Bazel packages where a single resource_strip_prefix isn't sufficient.)

Is there a use case where the resources need to be in that particular java_library jar?

Yes. In any instance where the set of jars I publish constitutes an interface between me and my users (e.g. SDKs), I do not want to get in the business of managing additional resources-only jars, as that adds deployment overhead and leaks build+SCM implementation details that my users shouldn't know/worry about.

I see that the flag was first introduced way back in 2018 at d559ebd. Would the Bazel team kindly shed some light on the motivations behind this change?

p.s. As an additional workaround (in case resource_jars truly goes away), I've begun looking into constructing a tree artifact containing my resource structure and feeding that to java_library.resources, but singlejar doesn't grok directories. I'll poke around more later.

[pierventre]

I ended up rewriting part of our toolchain and fixing the resources path using an external component (OSGIWrapper). FYI https://gerrit.onosproject.org/c/onos/+/25471

[yannbolliger]

Can someone point me to the documentation on how one should modify their bazel rules to use the new syntax?

In the simple cases you can simply replace this:

java_library(
    name = "your-lib",
    srcs = glob(["src/main/java/**/*.java"]),
    resource_jars = ["/src/main/resources"],
)

By

java_library(
    name = "your-lib",
    srcs = glob(["src/main/java/**/*.java"]),
    resources = glob(["src/main/resources/**"]),
)

Importantly, you also have to remove the java_library rule or file that generates the /src/main/resources target.