-
Notifications
You must be signed in to change notification settings - Fork 202
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
Add resources to the configuration file #730
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resources are files that are used at runtime, either when testing or running an application. These files can be generated by the build tool or present in a resource directory of a project. Resource files have been supported in bloop since 1.0, where in sbt and other build tools we were relying on the resources to be copied by the build tool to the classes directory. This approach had a problem: whenever a change is done in an unmanaged resource file (a file that is controlled by the user, like a `log4j2.properties` file), bloop would not pick it up until there's a new `bloopInstall` invocation. This is a known limitation that this commit fixes. The approach to support resources has changed: 1. A new `resources` field has been added to the JSON file. 2. Resources are not copied to the class file, they are instead added to the test and run classpaths. The second item makes a subtle but important point. The fact that we don't copy the resources means two things: 1. We don't care about the relative path with regards to the root resource directory where a resource lives. 2. We rely on the contents of the `resources` field, which should contain only those directories which are either considered roots (e.g. files from where the application can use relative paths to look for resources) or single files. We support this treatment of resources in all build tools. Sbt requires a special case in the plugin because the source of truth is `resources`, which contains all the contained files in the resource directories + any other file the user may have added. As a consequence, we filter the paths until we get either root resource directories or single source files. Note that removing directories that are already contained in a root resource directory is really important because it dictates the way the resource will be accessible at runtime (where the lookup relative paths play an important role). Fixes #586
jvican
added
enhancement
task / run
task / test
ergonomics
Any change that affects developer ergonomics and the easiness of use of bloop.
labels
Nov 22, 2018
The resources should always be in front of the classes directory of the same project to ensure that if the build tool adds the resources to the classes directory we override them with the source of the resources.
alexarchambault
approved these changes
Nov 22, 2018
jvican
added a commit
that referenced
this pull request
Jan 15, 2019
In #730, I claimed: > Resources are files that are used at runtime, either when testing or running an application. These files can be generated by the build tool or be present in a resource directory of a project. However, this was not the full story, it turns out that resources are also required by macros, which happen at compile time, and therefore resources are required by `compile`. This patch modifies bloop to use the classpath with resources as the default from now on for any action in bloop, as all of them require it. Fixes #763
jvican
added a commit
that referenced
this pull request
Jan 15, 2019
In #730, I claimed: > Resources are files that are used at runtime, either when testing or running an application. These files can be generated by the build tool or be present in a resource directory of a project. However, this was not the full story, it turns out that resources are also required by macros, which happen at compile time, and therefore resources are required by `compile`. This patch modifies bloop to use the classpath with resources as the default from now on for any action in bloop, as all of them require it. Fixes #763
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
ergonomics
Any change that affects developer ergonomics and the easiness of use of bloop.
task / run
task / test
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resources are files that are used at runtime, either when testing or
running an application. These files can be generated by the build tool
or be present in a resource directory of a project.
Resource files have been supported in bloop since 1.0, where in sbt and
other build tools we were relying on the resources to be copied by the
build tool to the classes directory. This approach had a problem:
whenever a change is done in an unmanaged resource file (a file that is
controlled by the user, like a
log4j2.properties
file), bloop wouldnot pick it up until there's a new
bloopInstall
invocation.This is a known limitation that this commit fixes. The approach to
support resources has changed:
resources
field has been added to the JSON file.the test and run classpaths.
The second item makes a subtle but important point. The fact that we
don't copy the resources means two things:
resource directory where a resource lives.
resources
field, which shouldcontain only those directories which are either considered roots (e.g.
files from where the application can use relative paths to look for
resources) or single files.
We support this treatment of resources in all build tools. Sbt requires
a special case in the plugin because the source of truth is
resources
,which contains all the contained files in the resource directories + any
other file the user may have added. As a consequence, we filter the
paths until we get either root resource directories or single source
files. Note that removing directories that are already contained in a
root resource directory is really important because it dictates the way
the resource will be accessible at runtime (where the lookup relative
paths play an important role).
Fixes #586