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

[Maybe] Make name derivation for Automatic Modules configurable #149

Open
jjohannes opened this issue Oct 16, 2024 · 0 comments
Open

[Maybe] Make name derivation for Automatic Modules configurable #149

jjohannes opened this issue Oct 16, 2024 · 0 comments
Labels
a:enhancement New feature or request

Comments

@jjohannes
Copy link
Member

Following up on this request.

As Java itself, this plugin produces invalid names for certain Jars if deriveAutomaticModuleNamesFromFileNames = true is used.

As @satsen pointed out, sometimes there are patterns in Jar names, which could be translated differently to get a valid result. Then not each of the invalid names need to be configured. A good example are Scala libraries, which always have the Scala vesion inside a Jar name. For example: circe-core_2.12-0.13.0.jar --> circe.core.2.12.

As a feature for this, I could imagine a configuration option that takes the same arguments as Java's String.replaceAll() and then applies that on the derived name.

deriveAutomaticModuleNamesFromFileNames = true
deriveAutomaticModuleNamesReplaceAll("\\.[0-9]+", "") // same semantics as String.replaceAll("\\.[0-9]+", "")
deriveAutomaticModuleNamesReplaceAll("circe\\.", "io.circe.")
// possibly more "deriveAutomaticModuleNamesReplaceAll()", will be applied in definition order

The above example would do:
circe-core_2.12-0.13.0.jar --name derivation-> circe.core.2.12 --replaceAll--> circe.core --replaceAll--> io.circe.core

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant