Missing groupId in maven packages (<parent> section in pom.xml files not consulted for groupId or version)

[proxity]

Description

As defined in https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Example_1

[...], if you want the groupId or the version of your modules to be the same as their parents, you can remove the groupId or the version identity of your module in its POM.

In gitea this triggers a problem. Simple example:

<project>
  <modelVersion>4.0.0</modelVersion>
 
  <parent>
    <groupId>com.mycompany.app</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0-SNAPSHOT</version>
  </parent>
 
  <artifactId>submodule1</artifactId>
</project>

Since the groupId is only specified in the <parent> section, it's not found and the package gets an empty groupId in its metadata.

See DB:

 id  | package_id | creator_id |   version    | lower_version | created_unix | is_internal |        metadata_json         | download_count 
-----+------------+------------+--------------+---------------+--------------+-------------+------------------------------+----------------
 250 |        113 |         78 | 1.0-SNAPSHOT | 1.0-snapshot  |   1713433435 | f           | {"artifact_id":"submodule1"} |              0

 

The UI shows:

<dependency>
    <groupId></groupId>
    <artifactId>submodule1</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

Gitea Version

1.21.10

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

The official docker container

How are you running Gitea?

The official docker container

Database

PostgreSQL

[JWT007]

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

[linghengqian]

• I noticed this problem when I was writing a Chinese article at https://www.yuque.com/linghengqian/meve2v/ibzgu87kwyf7612i and https://github.com/apache/shardingsphere/discussions/12258#discussioncomment-10427297 . 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.

[yuchen16]

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

[JWT007]

@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 :/

[linghengqian]

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.

[JWT007]

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.

[wxiaoguang]

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 )

[JWT007]

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

[wxiaoguang]

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 .......