Manifest resolution order in multi-release jar
Luke Hutchison
luke.hutch at gmail.com
Thu Oct 4 07:35:02 UTC 2018
JEP 238 says "JAR metadata, such as that found in the MANIFEST.MF file and
the META-INF/services directory, need not be versioned." However, if a
manifest file is present in the base layer *and* a version layer, what are
the correct semantics? e.g.
META-INF/MANIFEST.MF :
Multi-Release: true
X: 1
Y: 2
META-INF/versions/9/META-INF/MANIFEST.MF :
X: 3
I am guessing that META-INF/MANIFEST.MF is only read to check for
Multi-Release:
true , and if found, META-INF/versions/* is checked for versioned
META-INF/MANIFEST.MF entries, using the normal multi-release resolution
order. If one is found, that is read as the manifest file, in place of the
base layer manifest file that was already opened (and the rest of
META-INF/MANIFEST.MF , i.e. X: 1 ; Y: 2 is ignored). We end up reading only X:
3 as the manifest attribute values.
Is that correct? (If so, it's a bit of a "Shroedinger's cat" situation
here, since META-INF/versions/9/META-INF/MANIFEST.MF does not contain
Multi-Release:
true , but I assume this manifest entry is ignored or not needed once it is
established that this is a multi-release jar...)
Or should a versioned manifest file be "merged on top of" the base manifest
file, so we end up with Multi-Release: true ; X: 3 ; Y: 2 ?
(I am basing this question on the text of the JEP rather than any current
implementation, since as far as I can see, the JEP does not specify the
behavior, raising the possibility that this may change in the future.)
More information about the jigsaw-dev
mailing list