Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
proxity opened this issue Apr 18, 2024 · 7 comments · May be fixed by #32943

Comments

@proxity
Copy link

proxity commented Apr 18, 2024

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
Copy link

JWT007 commented Apr 21, 2024

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
Copy link

<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
Copy link

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

@JWT007
Copy link

JWT007 commented Sep 29, 2024

@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
Copy link

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
Copy link

JWT007 commented Sep 29, 2024

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 wxiaoguang linked a pull request Dec 22, 2024 that will close this issue
@wxiaoguang
Copy link
Contributor

wxiaoguang commented Dec 22, 2024

Two problems here:

  1. module inheritance

-> Fix maven pom inheritance #32943

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants