Determine if itext is still used and remove it if it is not
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
Start by searching the repository for iText dependencies and usages, especially the document writer and any direct user-code references mentioned in the issue. If it is unused, remove the dependency and update the release notes with the compatibility-version guidance and instructions link requested here. Done means confirming whether OIE uses iText and, if not, documenting its removal and how developers can acquire a compatible version with its transitive dependencies.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Based on a discord chat . User edthri had a scanner suggest that iText may not have a compatible license. This was not an issue since OIE and Mirth use iText 2.1.7 which is MPL. tonygermano replied that the iText dependency may not even be needed.
I don't think the document writer depends on it anymore. I'm not sure why it's still included other than there was a log of old user code that called it directly.
The scope of work sound be:
- Determine if iText is still in use in OIE
- If iText is not in use, remove it as a dependency
- Update release notes and clearly state iText is no longer present in Mirth and that developers will need to include it manually. Include a link to separate instructions for how to acquire a compatible version of iText and its transitive dependencies
- Lenguaje dominante
- Java
- Estrellas
- 227
- Forks
- 81
- Merge medio
- 3 d 6 h
- PR fusionados (30 d)
- 15
Preparar el entorno
- Incluye un Dockerfile o un 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 OpenIntegrationEngine/engine
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#485 ·
Los mantenedores suelen responder en 2 días
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
OpenIntegrationEngine/engine#478 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#355 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#347 ·
Los mantenedores suelen responder en 2 días
-
Fix call-home in test runAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenIntegrationEngine/engine#313 ·
Los mantenedores suelen responder en 2 días
Todos los issues de OpenIntegrationEngine/engine
Issues similares
-
[Bug] dubbo.protocol.triple.max-message-size is only read from OS environment variablesPosiblemente ocupada @CCCLL la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
hierynomus/sshj#1070 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
intellij-elixir/intellij-elixir#4492 ·
Los mantenedores suelen responder en 1 día
-
[Server] OpenAPI 3.1 YAML specs generate Object fields: resolveToJSON drops every schema typeAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
quarkiverse/quarkus-openapi-generator#1796 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
quarkiverse/quarkus-jooq#324 ·
Los mantenedores suelen responder en 1 día