Plexus

This is the underlying cause of MJAR-4

Do we really want the project description being placed in the Specification-Title field? Currently the description is used for the generated site's initial page, so I would expect the description to be rather long. Would it be possible to use the project title attribute for this value instead?

This bug does not only affect the description but also all vendor tags (pom.xml -> project.organization.name).

This causes a java.io.IOException (invalid header field) and makes it impossible to deploy a maven-generated war file to tomcat.

The solution is strip line feeds before.

I looked into the issue and found this:

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Name-Value%20pairs%20and%20Sections

section: *header +newline
nonempty-section: +header +newline
newline: CR LF | LF | CR (not followed by LF)
header: name : value
name: alphanum *headerchar
value: SPACE *otherchar newline *continuation
continuation: SPACE *otherchar newline
alphanum: {A-Z} | {a-z} | {0-9}
headerchar: alphanum | - | _
otherchar: any UTF-8 character except NUL, CR and LF

The spec seems to have allowed for multi-line elements (called continuation) since at least 1.3. Could the issue be in tomcat ?

This doesn't seem to be a tomcat issue because of the spec does only allow continuation: SPACE *otherchar newline one SPACE char after linefeed.

With pom.xml like:

<project...
  <organization>
    <name>My ultra fantastic, boombastic, funky organization in a town with this very very really very long name</name>
    ...

MANIFEST.MF turns out fine:

...
Specification-Title: ...
Specification-Vendor: My ultra fantastic, boombastic, funky organizati
 on in a town with this very very really very long name
Implementation-Vendor:...
...

But on using tho following pom:

<project...
  <organization>
    <name>My ultra fantastic, boombastic, 
      funky organization in a town with this very very really very long name
    </name>
    ...

MANIFEST.MF turns out weird:

...
Specification-Title: ...

Specification-Vendor: My ultra fantastic, boombastic, 
		  funky organ
 ization in a town with this very very really very long name
Implementation-Vendor: ...
...

I guess removing LF before reformating the description, organization, ... would fix this.

I don't see otherchar excluding other potential spaces. Isn't space a valid UTF8 character ? And tab as well?

On the other side, if you start you second description line with a tab, then you have an issue. So I think that \r\n are valid but \t shouldn't be.

The simplest solution I to makre sure there's a space at the beginning of each continuation line, add one if necessary. No stripping to do in that case. Markus, what do you think?

Hi Jerome,

you were right. I didn't notice, that my fresh installed eclipse did indent using TABs. I switched to spaces and everything is back to normal again.

THX

Here's the proposed fix. We need to handle all sorts of allowed newline characters. The old code only handled CRLF and LF if I recall well.

For those who cannot upgrade, there's a work-around: add at least one space as prefix to each line that represents the value of the Manifest entry that causes an issue. Hoping that there's not too much trimming around.

Fixed in svn revision 3145. Did not use patch.

kenney: thanks for the fix.

BTW, technically the StringTokenizer version, while cleaner, is slightly over-zealous in converting the newlines. \n\r should really be 2 newlines. That's also why I didn't pick it up initially. But I am not sure that there's a real use case matching this theorical issue.