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

Add resources to the configuration file #730

Merged
merged 2 commits into from
Nov 22, 2018
Merged

Add resources to the configuration file #730

merged 2 commits into from
Nov 22, 2018

Conversation

jvican
Copy link
Contributor

@jvican jvican commented Nov 22, 2018

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 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

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 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.
@jvican jvican merged commit 19b5d6a into master 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
@tgodzik tgodzik deleted the ticket/586 branch September 7, 2021 16:21
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't ignore changes to unmanaged resource files
2 participants