As new custom buildpacks are developped, new app file formats will arise
(e.g. .ear or .phar ...). The current cfoundry client has a limited number
of patterns that it supports and preprocesses/unzips. New unsupported
patterns are not detected as archives and thus not unzipped. This results
in buildpacks having to unzip the archive themselves, and make special
handling: for instance, the jonas container class  need to handle wars
as unzipped directories while ears are plain files.
I'm also suspecting unsupported formats won't benefit from the fingerprints
that allow to save bandwidth on uploads and would require the whole app
binary to be transmitted at each push.
Could we find a way to uniformly handle app formats/extensions so that
upcoming extensions in new buildpacks don't have to assume/handle the
special handling ? Could we imagine the buildpack to be used to express the
supported archive extensions, so that new extension dynamically get
registred in cfoundry. Should buildpack authors merely ask for a cfoundry
update for new 'zip' extensions to support ?
BTW, for wars, the default behavior of unzipping the war is kind of
lossless: the original app name is lost in the unzipping process.
Buildpacks that would like to expose apps on path relative to the war name
can't easily currently do this. How can buildpack authors for supported
types could retreive the original file name, or possibly control whether to
leave app bits are zipped/unzipped ?
Thanks in advance,