[groovy-user] Bug caused by gmaven-runtime artifact naming convention?

[Jason Smith]

Should I JIRA this? The naming convention of the gmaven-runtime-1.x artifacts seems to break Java/Maven in one specific case.

I have the following plugin definition for defining a MANIFEST in my JAR file.

Note that <addExtensions/> is "true".
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<index>true</index>
<manifest>
<mainClass>com.infotrustgroup.util.commandline.Main</mainClass>
<packageName>com.infotrustgroup.buildtools</packageName>
<addClasspath>true</addClasspath>
<addExtensions>true</addExtensions>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
<key>value</key>
</manifestEntries>
</archive>
</configuration>
</plugin>

This adds entries for all the extension libraries into the JAR file, like this:
...
joda-time-Extension-Name: joda-time
joda-time-Implementation-Version: 1.5.2
gmaven-runtime-1.5-Extension-Name: gmaven-runtime-1.5
gmaven-runtime-1.5-Implementation-Version: 1.0-rc-3
slf4j-api-Extension-Name: slf4j-api
slf4j-api-Implementation-Version: 1.5.0
gmaven-feature-support-Extension-Name: gmaven-feature-support
gmaven-feature-support-Implementation-Version: 1.0-rc-3
gmaven-feature-api-Extension-Name: gmaven-feature-api
...

Now when I run Java with -jar, like this:
java -jar "%~dp0\lib\BuildTools-1.0.6-SNAPSHOT.jar" "%~f0" com.infotrustgroup.buildtools.commands.Build %*

I get the following exception:
Exception in thread "main" java.io.IOException: invalid header field name: gmaven-runtime-1.5-Extension-Name
at java.util.jar.Attributes.read(Attributes.java:416)
at java.util.jar.Manifest.read(Manifest.java:182)
at java.util.jar.Manifest.<init>(Manifest.java:52)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:160)
at java.util.jar.JarFile.getManifest(JarFile.java:146)

I believe this is happening because of the 1.5 in the name. If I use gmaven-runtime-default, this does not happen. If set <addExtensions/> to "false", it also does not happen. So this is fairly easy to work around, but it is also pretty difficult to troubleshoot unless you know where to look.

Note that the code in the stack trace isn't mine. This is happening in Java, before my code ever gets called.

This one is pretty hard to produce at random, though it is repeatable. You have to be running compiled Groovy from within a JAR where you have set up the MANIFEST with extensions on.

One suggestion would be to call the artifact gmaven-runtime and set the version to 1.5, 1.6, whatever - the version of Groovy, plus maybe a point version and RC status. That would work, and it would not break the Java jarring mechanism.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jason Dillon]

Ya, I'd say add a JIRA, but really I think this is the fault of the
crappy manifest format. Might look into fixing if other complain
about it.

--jason

[Jason Smith]

I would agree to you that the manifest format is probably overly restrictive. I'd also suggest that the gmaven-runtime version convention should probably match the groovy artifact naming convention.

http://mvnrepository.com/artifact/org.codehaus.groovy/groovy

Or not. :-)
________________________________________
From: Jason Dillon [jason....@gmail.com] On Behalf Of Jason Dillon [ja...@planet57.com]
Sent: Sunday, January 11, 2009 9:46 PM
To: us...@groovy.codehaus.org
Subject: Re: [groovy-user] Bug caused by gmaven-runtime artifact naming convention?