"Jaikiran" wrote : However, the step of writing out to the file system | using an output stream is left to the client of the API: | | // Export to the Filesystem as a real JAR | | InputStream zipStream = ZipExporter.exportZip(archive); | | // Get a FileOutputStream and then write the contents of "zipStream" to it | | | Was this intentional? Yep. My feeling at the time (and may still be) was "everything in its place", and flushing the contents of an InputStream to a File (or any other resource) is a generic IO function better suited elsewhere. For instance, we don't see libraries which handle image manipulation providing this kind of utility. We can contrast that position with Aslak's: "aslak" wrote : We're trying to make the apis as convenient as possible to use, so a export option directly to file is probably not a bad idea. ...and arrive at a consensus. Other opinions? Also, the TMPDPL (temporary name) project in JIRA handles this abstractly, so for instance Archives may be deployed directly: * http://anonsvn.jboss.org/repos/common/tmpdpl/trunk/api/src/main/java/org/... < Container which supports deploying "Deployable" types. (I wonder if ShrinkWrap should be a dependency here, still a bit TODO there) * http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/api-embed... < Contract of the Embedded AS, which brings in "Container" support * http://anonsvn.jboss.org/repos/common/tmpdpl/trunk/impl-vdf/src/main/java... < A base implementation so archives may be represented as VDF Deployments. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261023#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...