You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[MWAR-353] Manifest still not written to exploded location #182
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.
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.
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
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:
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.
Activity
jira-importer commentedon Mar 22, 2017
Rustam Abdullaev commented
The same applies to pom.xml and pom.properties. Those are not written to META-INF during war:exploded.
jira-importer commentedon May 12, 2017
Arnaud BourrÃĐe commented
Workaround doesn't work with 3.1.0 as manifest goal was removed
jira-importer commentedon Feb 8, 2018
Jakub Bochenski commented
Karl Heinz Marbaise any chance you could post the "MavenArchiver configuration" that can be used to replace the lost functionality?
jira-importer commentedon Nov 11, 2019
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 inwar: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.
jira-importer commentedon Nov 13, 2019
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.0I 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
jira-importer commentedon Nov 13, 2019
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:
Also see for details https://maven.apache.org/shared/maven-archiver/index.html
Will that help?
jira-importer commentedon Nov 13, 2019
Robert Scholte commented
Jakub Bochenski I've tried to explain why the manifest file is not written to the folder when calling
explodedand what needs to change to do so.elharo commentedon Jul 31, 2026
The problem stems from how the
maven-war-plugincurrently orders its operations. When runningwar: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, andpom.propertiesfiles 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.