Suspicious modules under `com.javax0`
Michael1993 opened this issue · comments
Artifacts under javax0.com belong to Peter Verhas.
If you can find it in their GitHub repository (e.g.: jamal.core or geci.core) then it is valid.
After scrolling a bit in suspicious/naming.md, it seems fairly common to leave out the top-level domain from the beginning of your module name.
Maybe this case needs consideration? 🤔
Thanks for the pointer, Michael.
[...] leave out the top-level domain [...] Maybe this case needs consideration? 🤔
True. Although it would lead to (more) name clashes. Here's one example for such a pattern:
modules/maven-group-alias.properties
Line 8 in 4f23c27
If there are two or more foo.bar modules originating from:
com.foo.barnet.foo.barorg.foo.bar...
Which one should be mapped? First come, first serve? Most "prominent" (Who decides? Me?) first? That's how I created the maven-group-alias.properties mapping in the first place. In cases of JavaFX, Kotlin, Spring, Scala, and some others, it was an easy and safe "guess". But I don't want to update/maintain that mapping for every contributor. That's why I really like this "rule":
Module names must be reverse-DNS, just like package names, e.g.
org.joda.time.
Artifacts under
javax0.combelong to Peter Verhas.
If you can find it in their GitHub repository (e.g.: jamal.core or geci.core) then it is valid.
That's not easy to guess nor easy to automate.
Mapping from the exact Maven GroupID com.javax0.jamal to the start of module names with jamal -- would work for most of Peter's Jamal modules. Except for the Maven ArtifactID jamal-maven-plugin, which drops the plugin part...
Same goes for com.javax0.geci=geci.
I'll extend maven-group-alias.properties mapping with both entries. Let's see how this works out.
PS: I guess, this pair might prevent the module to be indexed anyway.
- 📀
jamal.core-com.javax0.jamal:jamal-core:1.0.1 - 📀
jamal.core-com.javax0.jamal:jamal-extensions:1.0.1
Looks better than expected. Nice.