Java manifest representation is not to spec
- Dominant language
- Go
- Stars
- 9.6k
- Forks
- 954
- Avg merge
- 23h 27m
- Merged PRs (30d)
- 48
Description
Today we express the output from parsing a java manifest as such:
```golang
pkg.JavaManifest{
Main: map[string]string{
"Manifest-Version": "1.0",
"Archiver-Version": "Plexus Archiver",
"Created-By": "Apache Maven 3.6.3",
},
NamedSections: map[string]map[string]string{
"thing-1": {
"Built-By": "?",
},
"2": {
"Other": "things",
},
},
}
```
However the spec (see https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#name-value-pairs-and-sections) does not mention that theses sections must be named. This leads to imperfect solutions such as adding a string index as the section name (like `2` in the example above).
We should rename `NamedSections` to `Sections` support a structure that is closer to `[]map[string]string` (which more closely matches the spec).
Note: This has downstream impacts to consumers and is a breaking change to the JSON schema.
Contributor guide
Research direction
No file or test is named. Locate the Java manifest parser and JavaManifest consumers, then compare the current NamedSections representation with the JAR specification linked in the issue. Done means unnamed sections use the requested Sections representation and downstream consumers and the breaking JSON schema change are handled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100