Support for multiple archive types

[Brian DePradine]

Hi,

As a part of the work that we are doing in the Liberty buildpack to add support for additional archive types, such as .ear and .eba (enterprise bundle archive) files, we have come across an issue that will make this more difficult than expected. Currently when a .war file is pushed to cloud foundry it is unzipped and the contents sent across. Based, on previous conversations that I have had on this forum I expect .ear files and .eba files to mimic this behaviour. The problem is that it can be quite difficult to identify what the original archive type was just by inspecting the contents that have been pushed across. This is especially true when inspecting the contents of .ear or .eba files which for all intent and purpose can look the same. In order to get around this problem it would be useful for the scenario where an archive is being pushed to cloud foundry to preserve the original archive name, and then make it available as a new property in VCAP_APPLICATION that can then be retrieved in the buildpack. Naturally, in the scenario where the contents of a directory are pushed then this new property would be unset. Does this sound feasible?

Brian

[James Bayer]

my initial thoughts are why should the cf clients expand archives at all before uploading? if there are many file de-dup hits, it can help lessen the upload size for low network throughput circumstances. but if the buildpack can either do the unzip of the archive on it's own or rely on the container to do something then any future archive can be supported without teaching clients about it.

scott truitt, mark kropf, ryan morgan and ben hale are people i suggest to work with on this. 

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Thank you,

James Bayer