[
https://issues.apache.org/jira/browse/MJAR-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14573741#comment-14573741
]
Amichai Rothman commented on MJAR-195:
--------------------------------------
Oops, looks like we had a race condition on those comments :-)
So we're in agreement. I think such a feature would be useful, since it would
allow the manifest to be created precisely by other means (manually, ant, other
plugin, etc.). The entry order doesn't matter to software parsing it,
obviously, but it does change it's readability by humans. The manifest format
was chosen to be a human-readable one, rather than a binary one, so why make it
difficultly-human-readbale? For example, when analysing the manifest OSGi
headers visually, mixed up sort order makes it harder. Another example would be
diffing two manifests - if one header is added, the whole order can change and
instead of one added line showing up in the diff, the whole file (other than
first entry, which must come first) shows up as modified. Those are two
examples that come to mind.
As for the automatically added entries, they are not required by the spec as
far as I know, and sometimes interfere. For example, the Built-By header
changes depending on who's running the build, making the build non-reproducable
across machines/users, which is a shame since I gather exact reproducibility is
one of the goals of Maven (seeing how it warns about implicit plugin version
numbers etc. for this reason).
I'm not saying this has to be the default, but adding an option to use the
existing manifest without it being meddled with can have real value to some
projects.
> Add option to use unmodified existing manifest file
> ---------------------------------------------------
>
> Key: MJAR-195
> URL: https://issues.apache.org/jira/browse/MJAR-195
> Project: Maven JAR Plugin
> Issue Type: Bug
> Affects Versions: 2.6
> Reporter: Amichai Rothman
> Assignee: Karl Heinz Marbaise
> Attachments: mftest.tgz
>
>
> Currently, the jar plugin performs various manipulations on the manifest
> file, such as adding some entries and shuffling their order, and lacks
> functionality such as removing entries (there are separate issues for those).
> The workaround for these should be the ability to use an existing manifest
> file, whether hand-crafted or generated by other means such as ant, however
> the jar plugin seems to always modify the manifest just before adding it to
> the jar, thus preventing any such workaround from working.
> Please add a configuration option that causes the jar plugin to simply use an
> existing manifest file (e.g. one specified via manifestFile) without
> modifying it in any way - just copying it as-is into the generated jar file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
