Improvements to `bndmanifest` to support parallel usage with PDE
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
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- build-system
Línea de trabajo
Comienza revisando el plugin bndmanifest y la implementación enlazada de bnd ManifestUtil. Compara el formato de Eclipse PDE solicitado con el comportamiento actual de copyTo y, después, investiga cómo un modo compareTo o copy podría informar de discrepancias en el manifest durante la compilación de Gradle. Se considera terminado cuando el formato deseado y el comportamiento ante discrepancias estén definidos y cubiertos por pruebas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
We would like to generate our manifests with the bndmanifest plugin.
Our idea is to generate the MANIFEST.MF file, but in a way that it stays compatible with the PDE tooling running inside the IDE. In this setup we would have the MANIFEST.MF file present in our Git Repo.
What already exists:
copyTo from the osgiBndManifest can be used like this:
osgiBndManifest {
copyTo 'META-INF/MANIFEST.MF'
}
A first limitation is that ManifestUtil from bnd is formatting the MANIFEST according to the spec (line should not exceed 72 bytes and so on).
For us this creates an artificial change in Service-Component: because the org.eclipse.pde.ds.annotations tooling in Eclipse creates one line per xml file in the OSGI-INF/ folder.
We would like both tools bndmanifest and PDE tooling to have the same formatting (the Eclipse one).
A second feature we would like to have:
We consider that the generated MANIFEST created by the bndmanifest should win over a manual change in the Eclipse IDE. But we would like to be able to detect those mismatch by having a build failure if the generated manifest does not match the current version.
So instead of copyTo this should be something like a compareTo option that fails the build if the MANIFEST file is not correct. Maybe with a possibility to copy instead of compare (think spotlessCheck vs spotlessApply).
Have you some opinion about this topic?
Would you accept a PR for features in this direction?
- Lenguaje dominante
- Java
- Estrellas
- 137
- Forks
- 33
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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 diffplug/goomph
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
Todos los issues de diffplug/goomph
Issues similares
-
area-deployment area-integrations triage:bot-seen
Dificultad 2/5 Medio día Aptitud para principiantes 86/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/flink-agents#1156 ·
-
[source-shopify] FAILED bulk operation without partialDataUrl is silently treated as successful Abiertoarea/connectors autoteam community connectors/source/shopify needs-triage team/use type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100