Fabian Meumertzheim
Fabian Meumertzheim
As this is tricky to reproduce, would you be interested in submitting a PR with the fixes required to get it to work on your machine?
@bazel-io fork 7.2.0
@keertk @iancha1992 FYI, I prepared this PR to verify compatibility with the new lockfile format. Happy to finalize it when 7.2.0 lands.
Thanks, I'm in the process of setting up a Windows VM for that. But I likely need to do it again after the actual release, so I'll wait for that.
> or, actually, if we could get rules_python to declare certain module extensions of theirs to be reproducible, we might be able to just remove all traces of them from...
@bazel-io fork 7.3.0
`osgi` and `aspectj` annotations(?) are not recognized by `ijar` and logs are flooded with the noise
@hvadehra Based on the logs, I think that these warnings are emitted for `java_import` targets, which always use ijar.
`osgi` and `aspectj` annotations(?) are not recognized by `ijar` and logs are flooded with the noise
@dkashyn-sfdc Are you using a recent version of rules_java and Bazel, which use a Graal Native Image of Turbine? Together with `--experimental_java_classpath=bazel`, I've found it to be faster on incremental...
`osgi` and `aspectj` annotations(?) are not recognized by `ijar` and logs are flooded with the noise
I submitted https://github.com/bazelbuild/bazel/pull/22072 to deduplicate the warnings.
Yes, https://github.com/hedronvision/bazel-compile-commands-extractor/issues/189#issuecomment-2118998582 sounds right to me. Dev tooling for a module ideally should not live in packages that are consumed by module users.