This also affects the sample mvn dependency:get command in the UI

mvn dependency:get -DremoteRepositories=https://gitea-url.com/api/packages/TEST/maven -Dartifact=:my-app:1.0-SNAPSHOT

• I noticed this problem when I was writing a Chinese article at https://www.yuque.com/linghengqian/meve2v/ibzgu87kwyf7612i and [Article Contribution] Welcome to Leave Your Article Link Here apache/shardingsphere#12258 (comment) . This uses the Docker Image of gitea/gitea:1.22.1-rootless.
• Gitea's web UI not only misses the groupId of Maven artifacts, but also the version of sub-dependencies, which is incorrectly displayed as ${project.version} instead of 5.5.1-SNAPSHOT.
• 
• However, it can still be manually modified for use in downstream projects.

<dependency>
  <groupId>org.apache.shardingsphere</groupId>
  <artifactId>shardingsphere-jdbc</artifactId>
  <version>5.5.1-SNAPSHOT</version>
</dependency>

• URLs like http://localhost:22345/testbloodline/-/packages/maven/org.apache.shardingsphere-shardingsphere-jdbc/5.5.1-snapshot are also weird from my perspective. Maven apparently allows the existence of 2 Maven artifacts with different groupId but the same artifactId. This URL does not correctly reflect the concept of groupId.

I got the same problem, this issue will affect searching and pulling

@yuchen16 - There are two problems with the display. The first is when the groupID is inherited from the parent as mentioned in the ticket description. The second is on the dependencies when "${project.groupId}" is used in the <groupId> tag of a dependency instead of explicitly specifying the groupId. This has not affected the maven functionality though - just a UI problem.

@linghengqian I am not sure I understood your last point... two artifacts with the same artifactId and different group-names is absolutely OK in a maven repository. It is the combination of groupId + artifactId that must be unique.

Both of these should be valid.

a.b.c:foobar
x.y.z:foobar

Where gitea made a bad descision about the separator '-' is the following:

<groupId>foo</groupId>
<artifactId>bar-jdbc</artifactId>
<version>1-SNAPSHOT</version>

<groupId>foo-bar</groupId>
<artifactId>jdbc</artifactId>
<version>1-SNAPSHOT</version>

These would both result in the same URL:
packages/maven/a.b.c-foobar-jdbc/1-SNAPSHOT

Although a '-' in a groupID is bad practice, it is not forbidden and perfectly valid.
For example:

<dependency>
    <groupId>commons-lang.wso2</groupId>
    <artifactId>commons-lang</artifactId>
    <version>2.6.0.wso2v1</version>
</dependency>

Why Gitea decided to use a '-' instead of a subpath '/' here I will probably never understand :/

Why Gitea decided to use a '-' instead of a subpath '/' here I will probably never understand :/

• @JWT007 This is where I get confused. I would say Gitea behaves inconsistently with both Github and GitLab when it comes to URL handling.

Why Gitea decided to use a '-' instead of a subpath '/' here I will probably never understand :/

• @JWT007 This is where I get confused. I would say Gitea behaves inconsistently with both Github and GitLab when it comes to URL handling.

Absolutely - this was IMHO simply a bad design decision.

Two problems here:

1. module inheritance

-> Fix maven pom inheritance #32943

2. path design

Yes, I also agree it's not a good design ..... but if we'd like to change it, it might be a "breaking" change.

Do you think it is a must to change it at the moment? If not, let's keep it for a while and propose some better (breaking) designs in the future.

(I added a FIXME in #32943 )

@wxiaoguang - well a fix would be great - but would probably require an automatic migration to resolve the "breaking" condition

well a fix would be great - but would probably require an automatic migration to resolve the "breaking" condition

I just thought about it again: maybe no need to "break": old keep as old, make new to be new. But I think it needs some tricks to make the new URL pattern work .......