Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to add support for file mapping of resources #2592

Open
crt-31 opened this issue Jan 28, 2025 · 1 comment
Open

Need to add support for file mapping of resources #2592

crt-31 opened this issue Jan 28, 2025 · 1 comment
Labels
difficulty / easy Any change that is easy to implement. feature priority / low Any change that has a low priority to be fixed.

Comments

@crt-31
Copy link

crt-31 commented Jan 28, 2025

Bloop should add support for file mapping of resource files (directories and single files) so they are available at custom 'jar' locations at runtime. Essentially be able to do something like make the file at src/main/resources/myfile.txt be available as a jar resource at /custompath/myfilerenamed.txt.

Rationale:
SBT and other Build Tools support this mapping of files to specific and arbitrary places into the jar. SBT does it using the "mapping" field; see https://www.scala-sbt.org/1.x/docs/Mapping-Files.html. If Bloop supported this, then the resources would be available in proper places during bloop run, bloop debug and bloop test.

Adding this functionality will make bloop more comprehensive and correct during bloop run/debug/test.

Suggested implementation:

  • In the bloop project.json file schema, add a resourceMapping field that allows you map from source (file or dir) to a jar-relative location.
  • Sbt-bloop should be able to read sbt's "mapping" field and put it into the project.json
  • At bloop run/test/debug, bloop would probably need to copy the files into the classes directory. (But it should be able to use its change detection to see if the original file changed to reduce copying).
  • But, it would only need to do the copy during run/test/debug (not necessarily , and probably ideally not, for every compile)

My main desire is for Bloop to handle single-file arbitrary mapping, which we currently rely on.

Note: This is kind of related to #1631.

@tgodzik tgodzik added feature priority / low Any change that has a low priority to be fixed. difficulty / easy Any change that is easy to implement. labels Jan 28, 2025
@tgodzik
Copy link
Contributor

tgodzik commented Jan 28, 2025

Thanks for reporting! I do not plan to work on this currently, but it would be possible to implement for sure. The change would need to span bloop-config, bloop sbt plugin and the recent changes I did around resource copying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty / easy Any change that is easy to implement. feature priority / low Any change that has a low priority to be fixed.
Projects
None yet
Development

No branches or pull requests

2 participants