[MASSEMBLY-737] Generated WAR file does not contain the same default manifest entries as created by the Maven WAR Plugin

[jira-importer]

Michael Osipov opened MASSEMBLY-737 and commented

I am repackaging a WAR file with some files exchanged. The original file contains following manifest entries:

Manifest-Version: 1.0
Built-By: osipovmi
Build-Jdk: 1.7.0_55
Created-By: Apache Maven 3.2.2
Archiver-Version: Plexus Archiver

The MANIFEST.MF generated by this plugin looks like:

Manifest-Version: 1.0
Created-By: 24.55-b03 (Oracle Corporation)
Archiver-Version: Plexus Archiver

while the descriptor looks very simple:

<assembly
    xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>deployable</id>
    <formats>
        <format>war</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <dependencySets>
        <dependencySet>
            <unpack>true</unpack>
            <useProjectArtifact>false</useProjectArtifact>
        </dependencySet>
    </dependencySets>
</assembly>

---

Affects: 2.5.2

Attachments:

• massembly-737.zip (2.22 kB)

[jira-importer]

Kristian Rosenvold commented

You need to make a small test project if you want /me/ to fix this :)

[jira-importer]

Michael Osipov commented

I am aware of that. This is pending next week.

[jira-importer]

Michael Osipov commented

Kristian, here is the promised test case, please have a look.

[jira-importer]

Michael Osipov commented

Kristian, is that an easy fix?

[jira-importer]

Kristian Rosenvold commented

I have no idea, I will be looking at it sometime in the coming week. I've targeted it for 2.5.3 but if it turns out to be complicated it'll probably get bumped on to a later release. The items currently on 2.5.3 in jira reflect my plan for a pre-christmas release :) Plans change...

[jira-importer]

Kristian Rosenvold commented

org.codehaus.plexus.archiver.jar.JarArchiver#initZipOutputStream is where the stuff happens. Unfortunately this issue is a lot more tricky than it sounds, since the manifest HAS to be the first file in the zip archive. You can specify which MANIFEST.MF file to use, which may solve your problem.

I'm thinking about solving the general problem of the manifest in a better way, and this issue is just another aspect in that regard.

[jira-importer]

Michael Osipov commented

Why has the manifest to be the first in the file? I have always assumed that all components use Maven Archiver throughout.

I am not particularily clinging to the same content of the manifest file but indicating that there should be no difference between a Maven WAR Plugin and a Maven Assembly Plugin generated WAR file.

[jira-importer]

Kristian Rosenvold commented

the jar specification requires that the manifest file be the first file in the archive (the zip file). This is a royal PITA, since any items that have to go into the manifest have to be known up-front. plexus-io/plexus-archiver is generally as deferred as possible, meaning it lazily resolves anything you ask it for. Currently the assembly plugin "solves" this by being 2-pass; it reads all of the files specified in all the assembly descriptors. If any of them contain "stuff" that is supposed to go into the descriptor it writes the appropriate descriptor. It would be possible to add the scan for existing manifests to this first pass of the archiver. I really don't like us being 2-pass over the source specifications in assembly and would really like to reduce this to a single pass operation. In this case we'd have to re-write the entire archive at the end if we discover things that are "worthy" of a manifest entry. I'm not entirely ready to claim defeat on this yet, but it really means that we need to be able to re-write the zip file with a new manifest entry (and preferably without decompressing/recompressing) on the fly. So the moment I give up on all these ambitions and accept the 2-pass strategy it all becomes simple. But I'm not here for "simple"

[jira-importer]

Michael Osipov commented

Thanks for the analysis. This seems like a long-term goal and several days of work if not even more. Could we meanwhile add a question to the Assembly FAQ? I highly doubt that you will fix this with 2.5.3 which is perfectly fine.

[jira-importer]

Kristian Rosenvold commented

With the changes in commons-compress 1.10 and plexus-archiver 2.10, fixing this issue should be a much simpler fix, almost trivial. These are not yet released, so it's a little while off.

[jira-importer]

Michael Osipov commented

Great, I'd be more than happy to try a working trunk version.

[jira-importer]

Michael Osipov commented

Kristian Rosenvold, time has passed and many changes happened to this plugin. Do you want me to retry with the most recent version? Should this issue be fixed now?

[jira-importer]

Kristian Rosenvold commented

Funny you mention it :) There has been some refactoring done in plexus-archiver that now allows it to handle all kinds of "weird" merges properly, some of which was done with this issue in mind. I will take a look at your testcase now, this should be solvable now :)