[ http://jira.codehaus.org/browse/MJAR-50?page=comments#action_70259 ]
Mike Laurie commented on MJAR-50:
---------------------------------
The problem has indeed been masked because of other fixes.
3 things left to consider:
* I _think_ newlines in manifest values hasn't actually been fixed in
maven-archiver
* maven-jar-plugin-2.0 has an explicit dependency on maven-archiver-2.0 so
jar-plugin pom needs updating if archiver-2.1 is to be used.
* The {{Embedded error: The attribute ... may not occur more than once in the
same section}} seems to be a new problem (regression) in archiver-2.1 - I've
reproduced it, and it stops me from testing the newlines issue. It's not
restricted to the Specification-Title attribute.
*Discussion:*
The issue at hand has been masked by changes in MJAR-39.
The fix in MJAR-39 ensures that the Specification-Title manifest attribute (if
included) now contains project name (not project description)
However, I found (like you, Dennis) that the Specification-Title was not in the
jar's manifest at all.
This is in turn an effect of MJAR-38 whereby the Specification-... elements are
not included by default.
I've just tested this in maven-archiver-2.1, which was released on 27th June,
and descriptions containing newline-tab combinations no longer cause an
{{invalid header}} error.
However , the pom for maven-jar-plugin-2.0 has an explicit dependency on
maven-archiver-2.0:
{code:xml|title=maven-jar-plugin-2.0.pom}...
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-archiver</artifactId>
<version>2.0</version>
</dependency>
...{code}
This means that by default it's still using the old archiver.
When I updated my local repository's pom for maven-jar-plugin-2.0 to require
version 2.1, I was able to test the new version.
Can the pom be changed, or a new version of it released? I'm not sure how
these things are done.
I discovered that the deviation from the jar spec is actually the inclusion of
linefeeds in the continuation lines which I don't think has actually been fixed.
For reference, here's part of the [jar spec from
Sun|http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Name-Value%20pairs%20and%20Sections],
indicating why the problem happened:
{noformat}
newline: CR LF | LF | CR (not followed by LF)
value: SPACE *otherchar newline *continuation
continuation: SPACE *otherchar newline
otherchar: any UTF-8 character except NUL, CR and LF
{noformat}
In an attribute value, a newline followed by a tab is not valid; a newline
followed by a space to indicate a continuation would be valid.
If there are further similar problems with jar manifests, then it may be the
plexus jar class that's at fault.
(org.codehaus.plexus.archiver.jar.Manifest)
I don't think it should allow a manifest attrubite to contain \r or \n
characters.
To ensure Maven doesn't add \r or \n chars to manifest attributes, they could
be stripped out in MavenArchiver:
{code:title=org.apache.maven.archiver.MavenArchiver line 107}
private void addManifestAttribute( Manifest manifest, String key, String
value )
throws ManifestException
{
// Use the empty string to suppress a Manifest entry
if ( value != null && !"".equals( value ) )
{
/*+*/
//Don't allow newlines in manifest attribute values - plexus jar
doesn't
// currently strip them out, and they can result in an invalid
manifest.
value=value.replace('\r',' ');
value=value.replace('\n',' ');
/*+*/
Manifest.Attribute attr = new Manifest.Attribute( key, value );
manifest.addConfiguredAttribute( attr );
}
}
{code}
I don't know why you get "Embedded error: The attribute "Specification-Title"
may not occur more than once in the same section"
I got the same error with the following configuration when I was trying to test:
{code:xml|title=pom build/plugins section}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Dodgy-Entry>
Here's a manifest entry with a newline
followed by a tab (actually several tabs)
</Dodgy-Entry>
</manifestEntries>
</archive>
</configuration>
</plugin>
{code}
This doesn't occur with archiver-2.0; in 2.0 the dodgy entry is successfully
written to the manifest with the incorrect manifest attribute format:
{noformat:title=snippet from resulting manifest}
Dodgy-Entry: Here's a manifest entry with a newline
followed b
y a tab (actually several tabs)
{noformat}
> "Invalid Header" in jar's Manifest (Specification-Title attribute) when tab
> char in pom Description
> ---------------------------------------------------------------------------------------------------
>
> Key: MJAR-50
> URL: http://jira.codehaus.org/browse/MJAR-50
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Mike Laurie
> Priority: Trivial
>
> I typed a <description> element into my pom; the description spanned 2 lines,
> and my text editor put a tab char at the beginning of the 2nd line.
> The project built correctly, but another project depended on the resulting
> jar.
> The compilation of the depending project failed with "invalid header" on the
> jar I'd just compiled.
> When I looked at the jar's manifest, I saw the Specification-Title attribute
> had the tab character still in it from the <description> element.
> Replacing the tab with spaces in the pom solved the problem.
> However, this was valid xml that caused a compilation problem, so I think
> it's a minor bug with the jar production code.
> Note that the full description is trimmed before going into the manifest, so
> any
> Easy to work around, but it would be nice if whitespace in the <description>
> element were consolidated into spaces before copying to the manifest.
> Doesn't need any fancy layout stuff - just any multiple instances of tabs,
> spaces, lf or cr should be replaced by a single space.
> Try (I haven't tried to compile this!):
> {code}
> public String consolidateWhitespace(String input){
> StringTokenizer st = new StringTokenizer(input);
> StringBuffer rv = new StringBuffer();
> while (st.hasMoreTokens()){
> rv.append(st.nextToken() + (st.hasMoreTokens()?" ":""));
> }
> return rv.toString();
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
