Skip to content

Make ConvertWith applicable to a larger scope #4514

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

Closed
2 tasks
asarkar opened this issue May 4, 2025 · 6 comments
Closed
2 tasks

Make ConvertWith applicable to a larger scope #4514

asarkar opened this issue May 4, 2025 · 6 comments

Comments

@asarkar
Copy link

asarkar commented May 4, 2025

Currently ConvertWith only applies to a single parameter, so, a method using the same converter more than once becomes extremely verbose.

void testMostVisitedPattern(
  @ConvertWith(IterableConverter.class) String[] username,
  @ConvertWith(IterableConverter.class) int[] timestamp,
  @ConvertWith(IterableConverter.class) String[] website,
  @ConvertWith(IterableConverter.class) List<String> expected) {...}

Deliverables

  • Make ConvertWith applicable to a method such that if no other converter is found or specified for a parameter, the method-level converter will be used.
  • Alternatively, provide a way to register converters globally, akin to what the Spring Framework does.
@scordio
Copy link
Contributor

scordio commented May 5, 2025

Alternatively, provide a way to register converters globally, akin to what the Spring Framework does.

Hi @asarkar, I'm working on #4219, which might help with your use case.

@asarkar
Copy link
Author

asarkar commented May 5, 2025

@scordio Your PR looks promising, but I didn’t see any documentation included in it. Do you’ve a write up explaining the design, and the intended usage?

@scordio
Copy link
Contributor

scordio commented May 5, 2025

Not yet. I'll finalize the PR in the upcoming days, including the documentation.

Conceptually, the intended usage is the following:

  • Implement the new ConversionService interface or extend the TypedConversionService abstract class
  • Provide the new implementation through the service loader, i.e., create resources/META-INF/services/org.junit.platform.commons.support.conversion.ConversionService with the fully-qualified class name of the new implementation

This way, ConversionSupport, used under the hood by DefaultArgumentConverter, will apply the custom conversion logic on all the relevant parameters.

@marcphilipp
Copy link
Member

I'm optimistically closing this as duplicate of #853.

@asarkar Would be great if you could test out @scordio's work when the PR is ready/merged.

@asarkar
Copy link
Author

asarkar commented May 5, 2025

@marcphilipp What would I have to do in order to test a feature that's not yet released? Use a nightly build from a non-Maven Central repo?

@marcphilipp
Copy link
Member

We publish snapshots for every commit to main to the https://oss.sonatype.org/content/repositories/snapshots/ Maven repo. So you'd have to add that repo to your build and change the version to 5.13.0-SNAPSHOT (after the PR is merged). Alternatively, you could check out the PR yourself, run ./gradlew publishToMavenLocal and consume the version from the local Maven repository.

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

No branches or pull requests

3 participants