Maven JAR Plugin
  1. Maven JAR Plugin
  2. MJAR-39

Maven Sets Manifest Attribute Values to Multi-Line Strings

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Maven version: 2.0.4
      Microsoft Windows XP [Version 5.1.2600]

      Description

      Maven will set a Manifest attribute's value to a multi-line string, which results in an invalid Manifest.
      By default, on its own, Maven adds a Specification-Title attribute to the Manifest, and sets its value to the POM's <description> element. If this is a multi-line value in the POM, Maven will insert it unchanged: and yield an invalid Manifest. Maven then can't even load the jar that it just created itself!
      I have filed another bug relating to the fact that it should not insert such an attribute by default: MJAR-38

        Issue Links

          Activity

          Hide
          Steven Coco added a comment -

          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.

          Show
          Steven Coco added a comment - 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.
          Hide
          Steven Coco added a comment -

          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.

          Show
          Steven Coco added a comment - 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 .
          Hide
          Steven Coco added a comment -

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

          Show
          Steven Coco added a comment - Oops: the first comment I made, which appears redundant with a self-reference, was intended for another issue. Sorry.
          Hide
          Jochen Wiedmann added a comment -

          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.)

          Show
          Jochen Wiedmann added a comment - 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.)
          Hide
          Wendy Smoak added a comment -

          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.

          Show
          Wendy Smoak added a comment - 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.
          Hide
          Mike Perham added a comment -

          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.

          Show
          Mike Perham added a comment - 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.
          Show
          Lukas Theussl added a comment - See: http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
          Hide
          Jochen Wiedmann added a comment -

          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.

          Show
          Jochen Wiedmann added a comment - 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.
          Hide
          Mike Perham added a comment -

          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.

          Show
          Mike Perham added a comment - 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.
          Hide
          Jochen Wiedmann added a comment -

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

          Show
          Jochen Wiedmann added a comment - Kenney is wrong. In other words, Mike's patch (for MJAR-38 and MJAR-39 ) should still be applied.
          Hide
          Jerome Lacoste added a comment -

          > 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.

          Show
          Jerome Lacoste added a comment - > 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.
          Hide
          Steven Coco added a comment -

          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.

          Show
          Steven Coco added a comment - 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.
          Hide
          Jochen Wiedmann added a comment -

          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.

          Show
          Jochen Wiedmann added a comment - 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.
          Hide
          Steven Coco added a comment -

          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
          Show
          Steven Coco added a comment - 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
          Hide
          Steven Coco added a comment -

          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.

          Show
          Steven Coco added a comment - 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.
          Hide
          Jerome Lacoste added a comment -

          > 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.

          Show
          Jerome Lacoste added a comment - > 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.
          Hide
          Jochen Wiedmann added a comment -

          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.

          Show
          Jochen Wiedmann added a comment - 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.
          Hide
          Mike Perham added a comment -

          Issue is verified fixed in 2.1. Thanks Jochen.

          Show
          Mike Perham added a comment - Issue is verified fixed in 2.1. Thanks Jochen.
          Hide
          Brett Porter added a comment -

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

          Show
          Brett Porter added a comment - though this is applied, when I set the jar plugin to use the archiver it still generates the elements
          Hide
          Brett Porter added a comment -

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

          Show
          Brett Porter added a comment - actually, won't fixing as MJAR-38 will remove it by default

            People

            • Assignee:
              Mike Perham
              Reporter:
              Steven Coco
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development