Import Maven Projects with groupId + artifactId + version to avoid duplicate error on import
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- java, vscode
- Área
- developer-experience, tooling
Línea de trabajo
Start by tracing the Maven project import flow in the vscode-java extension and how it detects duplicate groupId/artifactId values; the issue does not name files or tests. Check how import identity is formed and whether the existing maven.explorer.projectName setting participates. Done when the two sample projects with versions 1.0 and 2.0 can both be imported without duplicate errors.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The Problem
On importing Java projects we get errors like this:
23 Maven project(s) could not be imported due to duplicate groupId/artifactId. See the language server log for details.
We are using a multi-root workspace:
- Each root folder imports a Java multi-project project from a seperate git local repo.
- Each repo / folder is a set to a different release branch from the same git repo.
This means that each root folder contains substantially the same set of maven projects, with the same groupId(s) and artifactId(s), but with different version(s).
i.e. as indicated by the error, groupId + artifactId is duplicate / ambiguous,
but the combination groupId + artifactId + version is unique.
For our maven projects the property name is also unique.
Proposed Solution
It should be possible to configure which maven properties are used to import maven projects:
e.g. groupId + artifactId + version
or groupId + artifactId + name
Note the Eclipse IDE when properly configured supports our project structure. Eclipse is able make otherwise duplicate maven projects unique on import via the "Import Maven Projects / Advanced / Name Template" option.
Describe alternatives you've considered
We have seen the setting "maven.explorer.projectName": "${project.groupId}.${project.artifactId}-${project.version}", but that has no effect on project import.
How to Reproduce
The issue can be demonstrated with:
A trusted multi-root-workspace "foo" with two folders foo_one and foo_two imported:
workspace "foo"
├─foo_one
│ └── demo
│ └── pom.xml
└─foo_two
└── demo
└── pom.xml
foo_one is a maven project with this pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>foo.bar</groupId>
<artifactId>demo</artifactId>
<version>1.0</version>
<properties>
<maven.compiler.source>25</maven.compiler.source>
<maven.compiler.target>25</maven.compiler.target>
</properties>
</project>
foo_two is a maven project with this pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>foo.bar</groupId>
<artifactId>demo</artifactId>
<version>2.0</version>
<properties>
<maven.compiler.source>25</maven.compiler.source>
<maven.compiler.target>25</maven.compiler.target>
</properties>
</project>
The projects differ only in the version (1.0) vs (2.0)
My Setup
IBM Bob Version: 1.126.0+bob2.2.3
VSCode Version: 1.126.0
Bob Version: 2.2.3
Extension Pack for Java 0.31.2
Language Suppor for Java(TM) by RedHat pre-release 1.59.2026102008
Maven for Java 0.45.3
OS: Darwin arm64 27.0.0
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.3k
- Forks
- 550
- Merge medio
- 4 d 5 h
- PR fusionados (30 d)
- 14
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de redhat-developer/vscode-java
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
redhat-developer/vscode-java#4550 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
redhat-developer/vscode-java#4537 ·
Los mantenedores suelen responder en 1 día
-
bug need info
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
redhat-developer/vscode-java#4520 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
redhat-developer/vscode-java#4517 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Red Hat Not ActivatingAbiertobug documentation
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
redhat-developer/vscode-java#4516 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de redhat-developer/vscode-java
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Automattic/data-liberation-agent#953 ·
Los mantenedores suelen responder en 1 día
-
README に GitHub の組織のバッジを足すAbiertodocumentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
funmary-app/funmary#399 ·
Los mantenedores suelen responder en 1 día
-
area:curator enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
CassioDalla/Scrinalia#150 ·
Los mantenedores suelen responder en 1 día
-
status: needs-triage v1-bug-bash
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
a2ui-project/a2ui#3533 ·
Los mantenedores suelen responder en 1 día
-
backend enhancement priority:P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
geolens-io/geolens#3310 ·
Los mantenedores suelen responder en 1 día