Improvements to `bndmanifest` to support parallel usage with PDE

Open

#187 opened on Apr 20, 2022 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 25/100

Issue type: Feature
Clarity: Mostly clear
Activity status: Stale
Tech stack: java
Domain: build-system

Research direction

Start by reviewing the bndmanifest plugin and the linked bnd ManifestUtil implementation. Compare the requested Eclipse PDE formatting with the current copyTo behavior, then investigate how a compareTo or copy mode could report manifest mismatches during the Gradle build. Done means the desired formatting and mismatch behavior are defined and covered by tests.

Written by the indexing model from the issue text.

Description

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?

Dominant language: Java
Stars: 137
Forks: 33
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.