Maven Sets Manifest Attribute Values to Multi-Line Strings

This issue is related to MJAR-39 in that since it sets the Specification-Title element by default to the POM's <description> element, it easily can create an invalid Manifest.

This behavior is also happening in the War creation; and there are even more problems there. I have filed an issue on that: MWAR-34.

Oops: the first comment I made, which appears redundant with a self-reference, was intended for another issue. Sorry.

I wonder what a sensible solution for the problem could be. Things that come to my mind:

1.) Depend on the proposed patches for MJAR-38 and throw an Exception, if a Manifest attribute
contains line feeds. (The proposed patch would allow the user to supply a different value.)
2.) Silently replace the line feeds with blanks.
3.) Reduce the problem to the special case of Specification-Title. If the <description> element
contains line feeds, use the <name> element.

Personally, I would clearly suggest 1.)

From Jochen's list, I'd vote for #1 and a modified #3: Always use <name> for the Specification-Title, and not <description>.

As you can see in the External References above, this one caused a problem for the Struts Action 1.3.3 build.

What does the Maven 1.x JAR plugin do? I think it makes more sense to use <name> for Specification-Title personally. I also think (2) is a good idea - linefeeds are usually just human-friendly formatting and always illegal in a manifest so to remove them silently just makes sense. I don't see any reason to throw an exception.

As suggested by Mike, the attached patch contains the following changes:

• Carriage Returns and Line Feeds are replaced with Blanks in manifest values.
• The POM's <name> attribute is used as Specification-Title, and not the <description>
  attribute.

The patch is relative to the proposed patch for MJAR-38. However, the patch is
so minor, that it should be possible without problems to adopt it anyways.

According to Kenney this has been fixed in plexus-archiver for some time now. This may just be a case where the plugin needs to upgrade to the latest version to pick up the fix.

Kenney is wrong. In other words, Mike's patch (for MJAR-38 and MJAR-39) should still be applied.

> Kenney is wrong. In other words, Mike's patch (for MJAR-38 and MJAR-39) should still be applied.

I am not so sure. Aren't multiline attributes ('continuations') allowed in Manifest files? See http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html

Have you guys tried to force using the plexus-archiver 1.0-alpha-6? That's where the fix for PLX-185 went in.

HI. I'm the original poster...

Yes, multiline attributes are possible: continuing lines must start with a single space.

But when I posted the bug, Maven was not obeying the rules – if I remember right, it also even inserted a fully blank line, which is not legal.

Hope that helps.

Noone discusses the possibility of continuation lines, Steve. The question is: What are continuation lines? IMO, they are one very long (> 72 characters) line, which is split into several physical line. Jerome believes, they may contain new lines before splitting them.

Blank lines are legal, btw. The rule for continuation lines says: blank otherchar* lf, where otherchar may very well be a blank.

Hi.

Well, simply, lines in the manifest cannot be longer than 72 bytes – not characters, but UTF-8 encoded bytes.

So, if a given attribute value causes the first line of the name-value pair to exceed that, it needs to be broken across more than one line. That's all.

To do that, the lines after the first must be preceeded with a single space – not any whitespace, but only a single space character. – Presumably, if the attribute value so happens to contain some kind of white space at this location, only the first space character is stripped away and the remainder of the line is the continuing attribute value.

But then importantly also, the first blank line in the manifest separates the main attributes section from the rest, the per-entry attributes. So Maven can't put any fully blank lines in the manifest's main section. And it also can't do that in individual per-entry sections either.

But it will do that.

Does tht make sense?

I realized that I mixed up the posted test case; I posted a few issues at the same time and mixed files up, and this zip is not useful. I'll see if I can attach a better test case: but if I fail, you can make a simple POM, and set the <description> attribute literally like this:

<description>
This

is a problem.
</description>

Then Maven will scoop this up and place it into the manifest as the "Specification Title", and it will include the blank line and all the rest. This Jar is then invalid.

The section in the Jar specification titled "Notes on Manifest and Signature Files" explains the line length and breaking long lines.

Thanks!!

• Steven Coco

This is an appropriate test. The previous zip was a mixed up file, uploaded to the wrong issue. See the simple README in this zip for instructions.

> To do that, the lines after the first must be preceeded with a single space –
> not any whitespace, but only a single space character. –

The spec says:

value: SPACE *otherchar newline *continuation
continuation: SPACE *otherchar newline
otherchar: any UTF-8 character except NUL, CR and LF

otherchar doesn't exclude SPACE and I believe space is a valid UTF-8 character.

So according to my understanding, a continuation might start with more than one space.

What is invalid is an empty line in the wrong place. The fact that every continuation line starts with a space guarantees that a continuation line won't be mistaken into an "fully blank line".

Now it is true that in maven 2.0.4 (which uses plexus-archiver 1.0-alpha-3) there's an issue. Continuations were wrongly identified and the example <description> you posted would result in a broken Manifest.

So I would like to see whether the problems still appears if you force the use of a later plexus-archiver (at least version 1.0-alpha-6). I haven't had time to look into your latest test case.

Steve, I can confirm that I can reproduce the problem with maven 2.0.4 and your second zip file.

I have checked, and maven 2.0.4 is indeed using plexus-archiver-1.0-alpha-3, which does add carriage returns and line feeds to the manifest value, thus producing invalid manifest entries. The plexus-archiver doesn't, as of 1.0-alpha-4.

I have also verified, that version 2.1-SNAPSHOT of the maven-jar-plugin uses version 2.0.1 of the maven-archiver, which in turn uses plexus-archiver-1.0-alpha-4. In other words, the problem can be fixed by adding

<version>2.1-SNAPSHOT</version>

to the maven-jar-plugins configuration. (Which I have verified successfully.)

I recommend, that this issue be closed, which I cannot do.

Issue is verified fixed in 2.1. Thanks Jochen.

though this is applied, when I set the jar plugin to use the archiver it still generates the elements

actually, won't fixing as MJAR-38 will remove it by default