Rename project to comply with maven convention and rename artifact id to provide better general clarity

[hazendaz]

[see] (https://maven.apache.org/guides/plugin/guide-java-plugin-development.html)

While the underlying build does comply with trademark as maven sets out abit with name off slightly, the project name does not. The name change is trivial and should mostly be a no-op to everyone using it. Forks would need to rename themselves from what I recall but would still be connected. Further, I would make sure 'maven' is actually in the plugin name itself. That serves for clarity as well as following maven requirements.

Project name -> maven-git-commit-id-plugin to git-commit-id-maven-plugin
Artifact id -> git-commit-id-plugin to git-commit-id-maven-plugin

The artifact id rename could make use of maven artifact relocation pom so that users are able to quickly find out it's changed.

Understandably this is a big ask but will bring it in line with 99% of all other maven plugins in the wild. Only a few deviate this way. Further, with the big jumps this project has already made I get the feeling if this were accepted it would be version 5.

I'm also available to help in said transition where needed :)

As this project has further become modular, it also stands that if this is accepted that the underlying modules also get entirely named properly.

The downside: maven compliance on project name if they cared at all. The bigger downside is that it's confusing in IDEs when each module has to further state that it's called X in module Y when that is entirely unnecessary and conflicts with disk layout. While not a big deal for those with few projects, it's a considerable issue IMHO when 100s of projects are in one IDE.

Suggestions on modules. Note maven is specifically in each.

• git-commit-id-maven-plugin-parent
• git-commit-id-maven-plugin
• git-commit-id-maven-plugin-core

That alone would keep me from seeing the reality as this -> git-commit-id-plugin-core (in core) [maven-git-commit-id-plugin]. A huge ask, I know, but wanted to toss it out there since this project seems to be going through big changes ;)

[TheSnoozer]

Hello,
thank you for sharing your concern here publicly.
Let me start with I'm not a lawyer so everything here is my own interpretation of what is stated on the maven guide on how to name your project.

in short I'm aware of the guideline and have read it multiple times before and also thought that this plugin might "violate" the mentioned trademark. However every time I read it I came to the conclusion that this plugin might not violate the trademark. In practice the guideline talks about the naming in combination of using a specific group id. So the real question for me here is to understand what is meant as the "naming"? Is the name the thing that is specified in the pom, or everything including the github project name? IMHO the guideline uses a bit watery explanation here and since the "name" reference is always used alongside with a groupId my understanding of the "name" is the name within the pom (or more specific artifactId).

For every current pom this project does not mention maven:
https://github.com/git-commit-id/maven-git-commit-id-plugin/blob/247d9df70786fbde36dd837566203df696dac839/pom.xml#L10-L11
https://github.com/git-commit-id/maven-git-commit-id-plugin/blob/247d9df70786fbde36dd837566203df696dac839/maven/pom.xml#L11
https://github.com/git-commit-id/maven-git-commit-id-plugin/blob/247d9df70786fbde36dd837566203df696dac839/core/pom.xml#L12

If you extend the "name" to everything beyond what is specified in the pom (e.g. the github project) then perhaps yes this project would violate the guideline and the trademark. Let me perhaps open a Maven-Ticket and ask for more clarifications from the "official" side (or perhaps raise the question to trademarks@apache.org)

When following the Apache interpretation here and here it appears that the naming might fail the "confusing similarity" or "likelihood of confusion" test so renaming certainly would push the plugin to the safer side.

Let me explore that further and raise this question to the official side.

As a final thought for now:
I would not rename the git-commit-id-plugin-core and git-commit-id-plugin-parent since those are certainly maven independent (at least the idea is that the core can be used within a gradle project as well so renaming it to something maven specific sounds wrong).

[TheSnoozer]

Renaming the project on github without breaking any links was quite an easy task and can essentially be done through the github settings of the project.

At least https://github.com/git-commit-id/maven-git-commit-id-plugin and git clone git@github.com:git-commit-id/maven-git-commit-id-plugin.git still remain working and redirect to the renamed project (git-commit-id-maven-plugin).

This means that the discussion if and how this project might violate the trademark is off the table. What to do with forks? I think it would be somewhat unfeasonable to reach out to everyone and have their project renamed? There is also the remaining point that the name of the maven plugin currently does not follow the maven-plugin guidelines:
https://github.com/git-commit-id/maven-git-commit-id-plugin/blob/247d9df70786fbde36dd837566203df696dac839/maven/pom.xml#L11

On the topic of relocation I have found this guide. The question for now is if it's worth the hassle....not sure currently there is only the maven plugin....so perhaps it would become worth the effort when there is another implementation?

For now I think the "critical" part is addressed, it certainly would make sense to keep this issue open to have this renaming tracked somewhere (I kinda think it would make sense and would require to bump the major version - e.g. would become 5.0.0).

[hazendaz]

@TheSnoozer Thanks! I appreciate the time you invested on this. I've renamed my fork. It's too bad that doesn't seem to just magically happen. I know github desktop will warn me to switch though as soon as I pull up this repo. I've had it do that to me on others when ownership or otherwise changed. I guess that is one small way others might come to find the naming change.

I am fully with you on everything else. Not a lawyer either and happened to stumble on that specific site again which looks to have been updated from what I had recalled seeing a long time back which resulted in me changing some plugins I had taken over ownership through the years.

I think if 'gradle' piece was to come in that eventually it might make sense to make separate modules. And thus the naming as-is on the core pieces is spot on for those needs. A lot of busy work though for sure unless gradle support pops up ;)

[hazendaz]

Here is what github desktop does.

[hazendaz]

It doesn't auto update my fork though just the upstream. I guess a work in progress on their part.

[TheSnoozer]

Thanks for letting me know that at least github desktop flags this.

I can include it also in the release notes to increase awareness.

Yeah the gradle release creates a bit of work...but I guess that is somewhat overdue ;-)

[TheSnoozer]

Let me start with: Finally I have time to tackle this 👯
So let me make a proposal on renaming the artifacts:

parent pom

Current

<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin-parent</artifactId>

Proposal

Remove it (done), or call it

<groupId>io.github.git-commit-id/</groupId>
<artifactId>parent-pom</artifactId>

Actual Maven plugin

Current

<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>

Proposal

<groupId>io.github.git-commit-id</groupId>
<artifactId>git-commit-id-maven-plugin</artifactId>

Shared Library

Current

<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin-core</artifactId>

Proposal

<groupId>io.github.git-commit-id</groupId>
<artifactId>git-commit-id-plugin-core</artifactId>

Notes:

When going with the proposed structure, it would mean that we move away from the group pl.project13.maven. I need to find out if I can get oss-sonatype write-access to com.github.git-commit-id

Update As per https://issues.sonatype.org/browse/OSSRH-70074 and https://central.sonatype.org/changelog/#2021-04-01-comgithub-is-not-supported-anymore-as-a-valid-coordinate we can not use com.github.git-commit-id as groupId, but instead fall-back to io.github.git-commit-id which is just good IMHO.

Feedback is welcome.

Feature plugins could live under their respected name. E.g. for gradle:

<groupId>io.github.git-commit-id</groupId>
<artifactId>git-commit-id-gradle-plugin</artifactId>

Relocation

https://maven.apache.org/guides/mini/guide-relocation.html
Sample: https://repo1.maven.org/maven2/org/apache/commons/commons-io/1.3.2/commons-io-1.3.2.pom

[hazendaz]

Sounds great! For sonatype, after you open a ticket with them to write to that location, they simply look and confirm you are a write permissioned user and/or owner of the repo. So that is allowed and matches up with the project name as expected. 'com.github' is certainly expected as the hosting domain unless you own your own :) I have a number of projects up with similar setup.

[TheSnoozer]

Thanks for your quick feedback! Now I just need to get the things sorted :-D

Ticket is now created: https://issues.sonatype.org/browse/OSSRH-70074

[TheSnoozer]

Thanks again for your input on this!
This task is now done via #565.
The publication of the relocation-pom is now part of the release (#558).

Going ahead and close this.