The manifest creation has changed in the last release of the m1 jar
plugin [1], which I did a few weeks ago. It was basically done in
accordance with this issue [1]. I discussed it with Stephane a few days
ago as he implemented the same thing in the m1 war plugin (to be
released soon) and we seemed to agree that this is a good way to do it.
The basic requirement is that a user should be able to get
specification/version information about any class/package he is using
via the methods of the java.lang.Package class [2]. Therefore, I think
it is a good idea to have Maven fill in some default values, as long as
the user is able to override them. The only thing I would change now is
to use pom.name for Specification-Title (instead of pom.shortDescription).

HTH,
-Lukas

[1]
[2]
[3]
#wp90680

Brett Porter wrote:
I think this was compatible with how it had been done in Maven 1.
- Brett

Mike Perham wrote:

>I'm working on MJAR-38 and I don't like how Maven adds some arbitrary
>manifest entries. Specifically I'm referring to Specification-Title and
>Specification-Vendor. The patch for this issue allows the user to
>override these entries defined by Maven but I would actually just like
>to remove them so Maven does not create these entries at all. The user
>can still define them in their pom. Is there any reason to keep these
>entries (backwards compatability or some other reason)?
>>
>if ( project.getDescription() != null )
>{
>addManifestAttribute( m, entries, "Specification-Title",
>project.getDescription() );
>}
>>
>if ( () != null )
>{
>addManifestAttribute( m, entries, "Specification-Vendor",
>().getName() );
>}
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org
>>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

[My link numbering got messed up, it's difficult to count until three
when you haven't had coffee yet]

Lukas Theussl wrote:

The manifest creation has changed in the last release of the m1 jar
plugin [1], which I did a few weeks ago. It was basically done in
accordance with this issue [1]. I discussed it with Stephane a few days
ago as he implemented the same thing in the m1 war plugin (to be
released soon) and we seemed to agree that this is a good way to do it.
The basic requirement is that a user should be able to get
specification/version information about any class/package he is using
via the methods of the java.lang.Package class [2]. Therefore, I think
it is a good idea to have Maven fill in some default values, as long as
the user is able to override them. The only thing I would change now is
to use pom.name for Specification-Title (instead of pom.shortDescription).

HTH,
-Lukas

[1]
[2]
[3]
#wp90680

Brett Porter wrote:

>I think this was compatible with how it had been done in Maven 1.
>>
>- Brett
>>
>Mike Perham wrote:
>>
I'm working on MJAR-38 and I don't like how Maven adds some arbitrary
manifest entries. Specifically I'm referring to Specification-Title and
Specification-Vendor. The patch for this issue allows the user to
override these entries defined by Maven but I would actually just like
to remove them so Maven does not create these entries at all. The user
can still define them in their pom. Is there any reason to keep these
entries (backwards compatability or some other reason)?

if ( project.getDescription() != null )
{
addManifestAttribute( m, entries, "Specification-Title",
project.getDescription() );
}

if ( () != null )
{
addManifestAttribute( m, entries, "Specification-Vendor",
().getName() );
}

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

>>
>>

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) maven (DOT) apache.org
For additional commands, e-mail: dev-help (AT) maven (DOT) apache.org