Add support for JDT Debbuger and Test Infrastructure?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- java, typescript, vscode
- Área
- developer-experience, devtools, testing
Línea de trabajo
El issue no menciona archivos, pruebas ni puntos de entrada, así que primero hay que aclarar el alcance de la integración de la depuración y las pruebas de JDT con VSCode. Revisa las responsabilidades de la extensión existente de Java y de Microsoft helper-extension, y después identifica los límites relevantes entre Debug Adapter Protocol y Test Protocol. Se considera completado cuando exista un plan de implementación definido para la depuración unificada y la ejecución de pruebas con paridad respecto a las experiencias de Eclipse y CLI.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Today, the VSCode Java suite of extensions use only the JDT's Language Services. Debugging, Testing Infrastructure, and other miscellaneous abilities (such as project view) are done by Microsoft's Helper extensions.
While I have no disdain for the Microsoft extensions, I believe we should unify the experience across the full Eclipse IDE and VSCode. That is, the default debugger and test runners should be the one that is natively used by the Eclipse IDE, communicated to VSCode via the Debug Adapter Protocols and Test Protocols.
Why, you might ask? Mainly to unify the experience. Most VSCode Extensions do the same:
Microsoft's own C# Dev Kit uses the same debugger and internal engine as Visual Studio for debugging and running tests.
Oracle's Java Extension uses the same Debugger and Test Infrastructure as NetBeans, communicated to VSCode via LSP and DAP.
Also, the Java Debugger by Microsoft doesn't use DAP, it uses its own custom solution, and the Java test extension produces garbage outputs when running tests, rather than having parity with CLI.
Would be neat to have one unified experience across both the native Eclipse IDE, and VSCode.
Thank You.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.3k
- Forks
- 547
- Merge medio
- 20 h 9 min
- PR fusionados (30 d)
- 10
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 1/5 Menos de una hora Aptitud para principiantes 85/100
redhat-developer/vscode-java#4509 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
redhat-developer/vscode-java#4426 ·
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
redhat-developer/vscode-java#4506 · 3 comentarios · 4 reacciones ·
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
redhat-developer/vscode-java#4505 · 2 comentarios · 2 reacciones ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
redhat-developer/vscode-java#4504 · 3 comentarios · 1 reacción ·
Todos los issues de redhat-developer/vscode-java
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
bug v2
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
modelcontextprotocol/inspector#2458 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
carbon-design-system/ibm-products#9907 ·