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
Following up on this request.
As Java itself, this plugin produces invalid names for certain Jars if
deriveAutomaticModuleNamesFromFileNames = trueis 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.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