Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Improvements to `bndmanifest` to support parallel usage with PDE

Abierto
#187 2 comentarios 0 reacciones 0 asignados Ver en GitHub

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

enhancement

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

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de diffplug/goomph

Todos los issues de diffplug/goomph

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.