Sorry for the late reply, and thanks for looking into this,
It seems that this has been fixed - the jar plugin uses
${pom.specificationVersion} for the Specification-Version attribute
(when I last looked it was using ${pom.version}.
-----Opprinnelig melding-----
Fra: Ben Walding [mailto:[EMAIL PROTECTED]
Sendt: 19. august 2003 01:03
Til: Maven Developers List
Emne: Re: Jar manifest version format
I'm reading the spec, and I'm not seeing the same issue that you are.
Here is the classworlds-1.0-rc1 manifest
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: Apache Jakarta Maven
Built-By: maven
Package: com.werken.classworlds
Build-Jdk: 1.4.1_01
Extension-Name: classworlds
Specification-Version:
Specification-Vendor: The Werken Company
Specification-Title: classworlds: Java(tm) ClassLoader Management Fram
ework
Implementation-Version: 1.0-rc1
Implementation-Vendor: The Werken Company
Implementation-Vendor-Id:
Manifest-Version conforms to the specification Implementation-Version
also conforms to the specification
Notably (from JDK1.4 jar spec) -
o Implementation-Version : The value is a string that defines
the version of the extension implementation.
Or am I misunderstanding your issue?
//
dev wrote:
>Hello,
>
>I've a small problem using some third-party JARs produced by maven. The
>problem is that the version number in the project is not always a legal
>manifest version number. Version numbers can be almost anything, and
>the jar manifest version numbers are copied unmodified from the version
>tags in the pom. According to the manifest spec, manifest version
>numbers must be a dewey number - one or more groups of digits separated
>by '.'.
>
>There are a number of projects that include release tags such as rc1,
>beta1 etc... in the vesrion for the project, e.g. classworlds, jaxen.
>I'm trying to use these classes with the Avalon Merlin project, which
>requires strict adherence to the manifest spec.
>
>Would it be possible to tighten up the spec for the project version?
>Heres a suggestion:
>
> dewey number[-suffix]
>
>This would cater for the vast majority of version numbers in use
>currently. The pom could include a currentVersion.dewey sub-property
>which is set from the dewey prefix of the currentVersion property, and
>a currentVersion.tag set from the suffix. Users can then set either the
>currentVersion property itself, or build it from its constituents.
>
>Cheers,
>Mat McGowan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
