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 resource container selector resolver #3718

Merged

Conversation

mpkorstanje
Copy link
Contributor

@mpkorstanje mpkorstanje commented Mar 8, 2024

Overview

Resolve resource container selectors

As a follow up for #3630 and #3705 this adds a
addResourceContainerSelectorResolver()
method to EngineDiscoveryRequestResolver.Builder analogous to
addClassContainerSelectorResolver().

Points of note:

  • As classpath resources can be selected from packages, the package
    filter should also be applied. To make this possible the base path of
    a resource is rewritten to a package name prior to being filtered.

  • The ClasspathResourceSelector now has a getClasspathResources
    method. This method will lazily try to load the resources if not
    already provided when discovering resources in a container.

  • selectClasspathResource(Set<Resource>) was added to short circuit the
    need to resolve resources twice. And to make it possible to use
    this method as part of the public API,
    ReflectionSupport.tryToLoadResources was also added.


I hereby agree to the terms of the JUnit Contributor License Agreement.


Definition of Done

As a follow up for junit-team#3630 and junit-team#3705 this adds a
`addResourceContainerSelectorResolver()`
method to `EngineDiscoveryRequestResolver.Builder` analogous to
`addClassContainerSelectorResolver()`.

Points of note:

 * As classpath resources can be selected from packages, the package
   filter should also be applied. To make this possible the base path of
   a resource is rewritten to a package name prior to being filtered.

 * The `ClasspathResourceSelector` now has a `getClasspathResource`
   method. This method will lazily try to load the resource if not was
   not already provided when discovering resources in a container.

 * `selectClasspathResource(Resource)` was added to short circuit the
    need to resolve resources twice. And to make it possible to use
    this method as part of the public API,
    `ReflectionSupport.tryToLoadResource` was also added.
@mpkorstanje
Copy link
Contributor Author

We briefly discussed the problem in the team. Do you have a concrete use case that would require solving the problem of having a machine-independent identifier for re-running a test based on a non-unique classpath resource? Otherwise, maybe we can move forward as-is and see if it actually becomes a problem?

Haven't got any concrete examples in mind right now. So that seems reasonable.

@mpkorstanje mpkorstanje marked this pull request as draft August 27, 2024 19:58
@mpkorstanje mpkorstanje marked this pull request as ready for review September 1, 2024 18:10
Copy link
Member

@marcphilipp marcphilipp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating this PR! I'll discuss it with the team and will get back to you.

@marcphilipp marcphilipp merged commit 8f71c19 into junit-team:main Oct 29, 2024
15 checks passed
@marcphilipp
Copy link
Member

@mpkorstanje Thanks a lot! Do you have time to try out adopting this in Cucumber from a snapshot?

@mpkorstanje
Copy link
Contributor Author

Cheers! I've already had a work in progress. But it will need some updates. Shouldn't be too difficult.

cucumber/cucumber-jvm#2835

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants