incorrect <name> entry in pom ("core" instead of "cats-core")

[SethTisue]

if I do sbt coreJVM/publishLocal and inspect the resulting cats-core_2.11.pom I see:

    <name>core</name>

instead of the expected cats-core.

this then confused dbuild in the context of the Scala 2.12 community build, since the macro-compat project (attn @milessabin) also has a org.typelevel#core and the duplication caused dbuild to complain.

I am not a pom/maven/ivy jockey at all and I have basically zero idea what the implications of the <name></name> part of a pom are. but it seems plausible to me that this could cause other sorts of tooling type problems in other contexts.

I didn't check to see if other subprojects are affected.

after set name in coreJVM := "cats-core" or with

-  .settings(moduleName := "cats-core")
+  .settings(moduleName := "cats-core", name := "cats-core")

a correct pom is generated. what the difference between moduleName and name is I have no idea

[travisbrown]

My understanding was that name is supposed to be documentary / for human consumption (although I don't have a reference to back that up at the moment). That's not to say "cats-core" wouldn't make more sense for name, anyway, but my impulse is to be more suspicious about dbuild's use of it.

[ghost]

Full Pom ref.

First import point is that a Maven POM "contains all necessary information about a project, as well as configurations of plugins to be used during the build process". ie it is more like a .sbt file.

And:

name: Projects tend to have conversational names, beyond the artifactId. The Sun engineers did not refer to their project as "java-1.5", but rather just called it "Tiger". Here is where to set that value.

So name, I believe, should be the sbt project name, eg "core", by default and the artifactId used instead. (So can be used to know "what sbt project do have to override to..."). Downside is that the artifactId also includes scala version, but that is in fact an sbt convention with standard semantics.

[ghost]

So, I posted within 24 seconds of @travisbrown. Snap - I lose 😄

[travisbrown]

@BennyHill But you had the citation and I didn't, so let's call it a tie. :)

[SethTisue]

@cunei @eed3si9n @dwijnand could this be a bug in dbuild?

[eed3si9n]

I don't know this relates to Dbuild, but as @travisbrown and @BennyHill noted the name part is for human consumption, so you can put Tiger or core. For example sbt publishes io_2.11 with the name IO (all uppercase): https://repo1.maven.org/maven2/org/scala-sbt/io_2.11/1.0.0-M6/io_2.11-1.0.0-M6.pom

[cunei]

There is a difference between name and moduleName, although the details are a bit lost in the mist of time for me, concerning dbuild. In general they are identical, but moduleName is a sort of normalized form, and it is the one used to publish. For instance, in Play there is a Play-Java-JDBC, whose module name is play-java-jdbc, and the latter is used for publishing. It may very well be that I have to hunt down a name and replace it with a moduleName in dbuild; that happened before, for instance: lightbend-labs/dbuild@07711c4
I thought I tracked down all of that long ago, but maybe there is a duplication check that is still looking at name. I'll check.

[dwijnand]

Sounds like a bug in dbuild to me.

Nonetheless I personally wouldn't name an artefact at org.typelevel / cats-core_2.11 simply "core".

Also, btw, here's some more tooling interaction around project id, name and moduleName: #203 (comment)

[SethTisue]

just for the record, I realized I should diffed the POMs to be sure that <name> was the responsible section. the diffs are actually:

@@ -4,7 +4,7 @@
     <groupId>org.typelevel</groupId>
     <artifactId>cats-core_2.11</artifactId>
     <packaging>jar</packaging>
-    <description>core</description>
+    <description>cats-core</description>
     <url>https://github.com/typelevel/cats</url>
     <version>0.7.2-SNAPSHOT</version>
     <licenses>
@@ -14,7 +14,7 @@
             <distribution>repo</distribution>
         </license>
     </licenses>
-    <name>core</name>
+    <name>cats-core</name>
     <organization>
         <name>org.typelevel</name>
         <url>https://github.com/typelevel/cats</url>

but I see from the POM Reference that Alistair linked to that <description> is also just for human consumption. regardless, recording the diffs here for completeness.

[dwijnand]

sbt defaults description to name: https://github.com/sbt/sbt/blob/v0.13.12/main/src/main/scala/sbt/Defaults.scala#L1142

[ghost]

So ideally, say for cats core, we could have :

<name>Cats Core Module</name>
<description>The cats core module contains most core type classes and functionality. This module is required).</description>

Note my deliberately confusing use of Module 😄

[cunei]

Yes, I verified that in dbuild, where this particulat duplicate checking occurs, the name is checked instead of the moduleName. The data, however, percolates from afar; I need to track backwards where the incorrect value originates from. It may take a while until I debug the whole thing.

[SethTisue]

ok. so from the Cats side, the pom isn't actually incorrect, but it could probably stand some improvement, regardless. not sure whether y'all want to leave the ticket open — it would be reasonable to just close it, and there could be a separate "improve human-readability of metadata in Cats poms" ticket. (thanks, Dale, btw, for finding #203, very helpful)

in the community build, I can work around this.

@cunei thanks — let's discuss/track further in the dbuild repo: lightbend-labs/dbuild#188