Option to containerize JAR so that java applications can read MANIFEST.MF

Description of the issue:

Feature-Request: I have a spring boot application that exposes some metadata about the currently running application. i collect these metadata using the following snippet:

@Configuration
public class MetricsConfig {

    @Bean
    public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
        final Package pack = getClass().getPackage();
        return registry -> registry.config()
                .commonTags(
                // @formatter:off
"implementation-title",	Objects.toString(pack.getImplementationTitle(), "DEVault"),
"implementation-version", Objects.toString(pack.getImplementationVersion(), "DEV")
		// @formatter:on
                );
    }

}

If i start the application using the fat jar or as a library of another project this code works fine, however if i launch it using the generated docker image it only uses the fallback values. I assume this is caused by the missing META-INF/MANIFEST.mf file. Currently there is no way to specify these attributes and the plugin does not pull them by itself. (Similar to #159 )

These metadata are also used by Log4j2 (and other Logging frameworks) to include a version number with the stacktrace entries.

Expected behavior:

I would expect that the metadata would be present also in the docker image. / It should be possible to specify these metadata in the plugin’s configuration.

Steps to reproduce:

• Write a main class that prints: Main.class.getPackage().getImplementationVersion()
• Add build metadata to the jar plugin config (see below)
• Build the jar
• Run the jar
• It will show the version number of the project
• Build the docker image
• Run the docker image
• It will show null

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <configuration>
                <archive>
                    <manifest>
                        <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                        <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
                    </manifest>
                    <manifestEntries>
                        <Build-Time>${maven.build.timestamp}</Build-Time>
                    </manifestEntries>
                </archive>
            </configuration>
        </plugin>

Environment:

• Maven 3.5
• Java 8
• Windows 10

(but I assume this is a general issue)

Possible Workaround

Move docker packaging to its own project that uses the original project as (jar) dependency.

[ivan-gammel]

I’d vote for opt-out from JAR packaging via configuration setting rather than for opt-in: jar packaging and manifest are so common and standard way to build the apps, that it naturally leads to unpleasant surprise for many developers that passing the build details like implementation version via manifest does not work.

The benefits related to incremental .class overlays (saving probably less than 100Kb) and reduced build time (by few seconds) for many would be insignificant.

[briandealwis]

I think most Java code would assume that they were packaged in a jar file. Especially when your build packaging is a jar packaging.

It doesn’t seem unreasonable to support something like a <package>classes</package> or <package>jar</package> option.