rules_jvm_external
rules_jvm_external copied to clipboard
WIP: proof of concept for license splicing
@danielmachlab This is proof of concept of the license lookup indirection.
I am not happy that we can't get a fallback repository. But, it could be done in setup, with the requirement that you call setup.
This is quite annoying.
- The primary setup method
rules_jvm_external_deps()
callsmaven_install
to create the reporules_jvm_external_deps
- so maven_install can't load the the classifier repository unless that was created
- but the place you want to create it is in
rules_jvm_external_deps()
- then the
setup
method depends on the reporules_jvm_external_deps
Sigh...
@aiuto this workflow looks good, especially considering the restrictions we have. It all works locally for me. What should the next steps be? It might be useful to get a third opinion on the direction we are heading in while finishing up the prototype lookup_license
function. I can make a PR tomorrow or Friday into this PR to fill in the lookup_license
function.
I don't know. I don't really like that you need a third setup function for this repository. I want to get the @license_checker repository injected by one of the first rules, so that all the examples don't have to change. My thought is that I could point to rules_jvm_external for the checker as a default, and add an optional rule that rewrites the dependency reader to point to the other repository.
But... you could certainly use what I have here to test the license injection at your scale.
I'm quite confused about what's happening here. Is there an issue/context for this FR?
Hi @jin we are trying to find a good way to allow users of rules_jvm_external to apply rules_license license
s to the artifacts that they import with maven_install
. This is coming out of the new rules_license SIG (see monthly meeting notes here). Here is a document which describes our problem and our original approach for this change. The initial approach didn't work out since we can't pass a macro to a repository rule.
Hi @aiuto, circling back to this. In this approach, why couldn't we make it so it is backward compatible where users not using a license classifier can avoid adding use_default_license_classifier()
to their WORKSPACE
?
I'm thinking that the optimal case would be for a user to:
- create a file defining
lookup_license
- load
set_license_classifier
from rje, which accepts the path of thelookup_license
file.