Skip to content

[MWAR-353] Manifest still not written to exploded location #182

Open

Description

@jira-importer

Jakub Bochenski opened MWAR-353 and commented

If I have no manifest files I don't get anything in the exploded location.
If I put a MANIFEST.MF under webapp folder's META-INF/MANIFEST.MF I just get the static file.
If I set archive/manifestFile to point at some file I just get the static file.

Workaround: change

<goals> 
  <goal>exploded</goal> 
</goals>

to

<goals> 
  <goal>manifest</goal> 
  <goal>exploded</goal> 
</goals>

and add the generated files to SCM ignore.


Affects: 2.6

Issue Links:

  • MWAR-418 Manifest not written to exploded location
    ("is duplicated by")

  • MWAR-379 manifest goal violates general Maven principle and creates file into src/main/..

  • MWAR-167 Final manifest not written to exploded location

  • MWAR-197 war:manifest does not add "manifestEntries" to generated manifest

3 votes, 4 watchers

Activity

  1. jira-importer commented on Mar 22, 2017

    @jira-importer
    Author

    Rustam Abdullaev commented

    The same applies to pom.xml and pom.properties. Those are not written to META-INF during war:exploded.

  2. jira-importer commented on May 12, 2017

    @jira-importer
    Author

    Arnaud BourrÃĐe commented

    Workaround doesn't work with 3.1.0 as manifest goal was removed

  3. jira-importer commented on Feb 8, 2018

    @jira-importer
    Author

    Jakub Bochenski commented

    Workaround doesn't work with 3.1.0 as manifest goal was removed

    Karl Heinz Marbaise any chance you could post the "MavenArchiver configuration" that can be used to replace the lost functionality?

  4. jira-importer commented on Nov 11, 2019

    @jira-importer
    Author

    Robert Scholte commented

    The code currently works like this: first create an exploded war ( as in war:exploded ), use this as input for the war ( as in war:war ).
    The latter is responsible for adding files like MANIFEST.MF, pom.xml and pom.properties.
    One solution would be to reverse this, so the exploded war looks exactly like the warfile, but that needs a huge rewrite, feeding the archiver with the right resources.

  5. jira-importer commented on Nov 13, 2019

    @jira-importer
    Author

    Jakub Bochenski commented

    Robert Scholte I'm not sure if you are responding to my previous comment or not. I was just asking for a workaround that works past 3.1.0

    I was referring to the comment from MWAR-379 by Karl Heinz Marbaise: "Removing the whole goal cause this can be handled simply with MavenArchiver configuration. "
    I would very much like to see an example MavenArchiver configuration that does that

  6. jira-importer commented on Nov 13, 2019

    @jira-importer
    Author

    Karl Heinz Marbaise commented

    Jakub Bochenski Have you taking a look into the documentation of the exploded goal given an example what kind of things can be configured take a look here:

    <project>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.3</version>
            <configuration>
              <archive>
                <addMavenDescriptor/>
                <compress/>
                <forced/>
                <index/>
                <pomPropertiesFile/>
                <manifestFile/>
                <manifest>
                  <addClasspath/>
                  <addDefaultEntries/>
                  <addDefaultImplementationEntries/>
                  <addDefaultSpecificationEntries/>
                  <addBuildEnvironmentEntries/>
                  <addExtensions/>
                  <classpathLayoutType/>
                  <classpathPrefix/>
                  <customClasspathLayout/>
                  <mainClass/>
                  <packageName/>
                  <useUniqueVersions/>
                </manifest>
                <manifestEntries>
                  <key>value</key>
                </manifestEntries>
                <manifestSections>
                  <manifestSection>
                  <name/>
                  <manifestEntries>
                    <key>value</key>
                  </manifestEntries>
                  <manifestSection/>
                </manifestSections>
              </archive>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </project>

    Also see for details https://maven.apache.org/shared/maven-archiver/index.html
    Will that help?

  7. jira-importer commented on Nov 13, 2019

    @jira-importer
    Author

    Robert Scholte commented

    Jakub Bochenski I've tried to explain why the manifest file is not written to the folder when calling exploded and what needs to change to do so.

  8. elharo commented on Jul 31, 2026

    @elharo
    Contributor

    The problem stems from how the maven-war-plugin currently orders its operations. When running war:exploded, it creates the exploded directory structure first. It then uses that exploded directory as the input for generating the final WAR file (war:war).

    The plugin's internal architecture delegates the creation of the MANIFEST.MF, pom.xml, and pom.properties files exclusively to the final archiving step. Because these files are generated and injected directly into the compressed archive by the Maven Archiver, they are never written back to the exploded directory.

    Fixing this would require a substantial rewrite of the plugin's internal workflow so that all metadata files are generated in the exploded directory prior to archiving, rather than injecting them during the compression phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority:majorMajor loss of function

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions