Executing the following Code on a current LGoodDatePicker release JAR file outputs "fails":
try (JarInputStream jarStream = new JarInputStream(new FileInputStream("LGoodDatePicker-11.1.0.jar"))) {
if (jarStream.getManifest() != null) {
System.out.println("passes");
} else {
System.out.println("fails");
}
}The reason for this is that the JarInputStream assumes that the first two JarEntrys contain the MANIFEST.MF file or the META-INF folder directly followed by the MANIFEST.MF file.
public JarInputStream(InputStream in, boolean verify) throws IOException {
super(in);
this.doVerify = verify;
// This implementation assumes the META-INF/MANIFEST.MF entry
// should be either the first or the second entry (when preceded
// by the dir META-INF/). It skips the META-INF/ and then
// "consumes" the MANIFEST.MF to initialize the Manifest object.
JarEntry e = (JarEntry)super.getNextEntry();
if (e != null && e.getName().equalsIgnoreCase("META-INF/"))
e = (JarEntry)super.getNextEntry();
first = checkManifest(e);
}see the code here
This assumption fails for LGoodDatePicker JAR files because we use the maven-shade-plugin to remove the default MANIFEST.MF from the JAR file and add a custom one instead. This supposedly places the new MANIFEST.MF file at the end of the JAR stream, not the beginning. As a result our new MANIFEST.MF file is not found by JarInputStream.
|
<plugin> |
|
<groupId>org.apache.maven.plugins</groupId> |
|
<artifactId>maven-shade-plugin</artifactId> |
|
<version>3.1.1</version> |
|
<executions> |
|
<execution> |
|
<phase>package</phase> |
|
<goals> |
|
<goal>shade</goal> |
|
</goals> |
|
<configuration> |
|
<shadedArtifactAttached>true</shadedArtifactAttached> |
|
<shadedClassifierName>core</shadedClassifierName> <!-- Any name that makes sense --> |
|
<createDependencyReducedPom>false</createDependencyReducedPom> |
|
<transformers> |
|
<!-- Note: Do not include any other transformers or lines which |
|
might cause maven or shade to create a manifest file. --> |
|
<!-- This will exclude any other manifest files from the jar, besides my custom manifest file. --> |
|
<transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer"> |
|
<resource>MANIFEST.MF</resource> |
|
</transformer> |
|
<!-- This will add my custom manifest file to the jar. --> |
|
<transformer implementation="org.apache.maven.plugins.shade.resource.IncludeResourceTransformer"> |
|
<resource>META-INF/MANIFEST.MF</resource> |
|
<file>src/main/resources/META-INF/MANIFEST.MF</file> |
|
</transformer> |
|
</transformers> |
|
<minimizeJar>true</minimizeJar> |
|
</configuration> |
|
</execution> |
|
</executions> |
|
</plugin> |
Executing the following Code on a current LGoodDatePicker release JAR file outputs "fails":
The reason for this is that the
JarInputStreamassumes that the first twoJarEntrys contain the MANIFEST.MF file or the META-INF folder directly followed by the MANIFEST.MF file.see the code here
This assumption fails for LGoodDatePicker JAR files because we use the maven-shade-plugin to remove the default MANIFEST.MF from the JAR file and add a custom one instead. This supposedly places the new MANIFEST.MF file at the end of the JAR stream, not the beginning. As a result our new MANIFEST.MF file is not found by
JarInputStream.LGoodDatePicker/Project/pom.xml
Lines 249 to 280 in 3dbc9aa