As this makes Processors part of the public API, I believe we should also move them out of the org.semver4j.*internal*.range.processor package. Do you agree @piotrooo?

As this makes Processors part of the public API, I believe we should also move them out of the org.semver4j.*internal*.range.processor package.

I've done that now in a new commit.

@sschuberth thanks for the contribution!

I think we need to merge #299 first, release a new version, and then address your PR. WDYT?

I think we need to merge #299 first, release a new version, and then address your PR. WDYT?

I haven't looked deeply into the implementation of that PR. I realize it could create some minor conflicts with mine, but given that the PR / underlying issue was open much longer, I agree that it should go first.

@piotrooo, this is ready for review again.

@piotrooo, this is ready for review again.

Any idea about the Java 8 failure? Was that the reason to downgrade maven-surefire-plugin?

Any idea about the Java 8 failure? Was that the reason to downgrade maven-surefire-plugin?

Yes, that was the reason...
I'll be preparing version 6 of the library without support for that dead Java 😄

For your convenience, I've dropped Java 8 from CI already in my branch, so you could cleanly merge it if there are no other review findings.

For your convenience, I've dropped Java 8 from CI already in my branch, so you could cleanly merge it if there are no other review findings.

I suggest aligning the version of maven-surefire-plugin with main, without removing anything from the CI workflow.

Ok, I've dropped my first and last commit then.

And even more importantly, why do I need it?

One reason is to allow something that was possible before, in the original library from @vdurmont: Originally, we were able to explicitly construct an Ivy-only version range by using Requirement.buildIvy(), but ever since the switch to RangesListFactory.create() implicitly all version ranges were supported.

As we are partly dealing with version ranges in configuration files written by users, i.e. version ranges are user input, this opens a can of worms for us to also document any other syntaxes besides Ivy. And if this library ever supported more syntaxes, we'd need to adjust our docs again.

So to keep things simpler, not confuse the user, and also lower the risk of running into bugs / conflicts between version range syntaxes, we'd prefer to stay explicit here about which syntax(es) is / are supported.

how should I use this function?

Well, see the added test case.

I'm aiming to use it in this (Kotlin) code to limit the supported range syntax to Ivy, so

RangesListFactory.create(version).takeUnless { it.get().isEmpty() }

becomes

RangesListFactory.create(version, IvyProcessor()).takeUnless { it.get().isEmpty() }

Maybe this feature deserves a separate section in the README with some use cases?

I could add something to the README if required, but I actually believe the docs / test to be sufficient.

Thanks ❤️