ijar incorrectly handles MANIFESTs with sections

[liucijus]

Description of the problem:

ijar tool incorrectly handles MANIFEST files with sections by removing empty lines and appending main attribute Target-Label after them.
I've faced this issue by trying to use java_common.stamp_jar on external jars.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Repro: https://github.com/liucijus/ijar-stamping-repro

What operating system are you running Bazel on?

Linux (Xubuntu 20.04)

What's the output of bazel info release?

release 3.7.2

[ittaiz]

@dslomov @dslomov @comius this is blocking rules_scala's ability to stamp 3rd party jars.
@liucijus sent a really small PR to fix this and we'd really appreciate it if someone could review it

[ittaiz]

@comius may I ask why this is P3?
IMHO this is at least a P2. The reason java rules use stamping is to avoid memory issues of passing long lists of labels.
We (at Wix and rules_scala) have been working for the past 6 months on being able to move to stamping to solve these issues but are facing many issues.
This is one of them.

[comius]

@comius may I ask why this is P3?
IMHO this is at least a P2. The reason java rules use stamping is to avoid memory issues of passing long lists of labels.

No, it's P3 - meaning we are accepting community PRs. P2 - somebody in the team would be working on it.

We (at Wix and rules_scala) have been working for the past 6 months on being able to move to stamping to solve these issues but are facing many issues.
This is one of them.

Sorry to hear that. Let me see if I can speed this up a bit. In the future "friendly ping" on the PR would suffice. github has a lot of noise and it's hard to see if there is PR that's been waiting for a long time. Keeping a queue of PRs in my mind just doesn't work everytime.

Ideally we'd review things in a week or two, but there are large discrepancies among PRs, so my guess is I'm not the only one having problems keeping up.

[ittaiz]

No, it's P3 - meaning we are accepting community PRs. P2 - somebody in the team would be working on it.

I see. I was looking through the bazel site for explanation on the priorities meaning and the classification of P3 was something super minor or something along those lines.
I think it's valuable adding your explanation to that doc.

In the future "friendly ping" on the PR would suffice

I did do that twice, just didn't know how to continue...

In any case thank you so much for advancing this!