ShrinkWrap Export to File

[alrubinger]

"Jaikiran" wrote:

I happened to try out the ShrinkWrap (1.0.0-alpha-1) this weekend.
Pretty useful stuff, especially in test case environments :) I read
through the project wiki http://www.jboss.org/community/wiki/ShrinkWrap
and even tried out my own few testcases. Works great!

One of things that i noticed in my tests was that i kept repeating a
piece of boilerplate code. As shown in the example in your wiki for
exporting jars (wars, ears etc...) we get hold of the InputStream from
the ZipExporter. 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? In my tests, after exporting, i had to almost
always write out the stream to the file. Although it's not complicated,
clients of the API could probably avoid this extra code if the
ShrinkWrap API added a new API which accepts the File to which the
archive has to be exported?

Something like:

void ZipExporter.exportZip(archive, File outputFile)

Thoughts?

[alrubinger]

"aslak" wrote:
Hey Jaikiran!

Looks like we have user # 2.. :)

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.

There is a 'Container' API under development that will have direct support for the Archives themselves. For instance using Jboss Embedded you can deploy the created Archive, so no need to export it to file first.

ps: The ShrinkWrap API is under change at the moment, as outlined here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161756

[alrubinger]

"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/jboss/tmpdpl/api/container/Container.java < 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-embedded/src/main/java/org/jboss/bootstrap/api/embedded/server/JBossASEmbeddedServer.java < Contract of the Embedded AS, which brings in "Container" support

* http://anonsvn.jboss.org/repos/common/tmpdpl/trunk/impl-vdf/src/main/java/org/jboss/tmpdpl/impl/vdf/VfsVdfDeployableImpl.java < A base implementation so archives may be represented as VDF Deployments.

S,
ALR

[jaikiran]

"ALRubinger" wrote:

Also, the TMPDPL (temporary name) project in JIRA handles this abstractly, so for instance Archives may be deployed directly:

...

The usecases where i think this functionality of exporting to files is going to be useful, is when ShrinkWrap starts getting used as a tool to dynamically generate archives, replacing the current approach of the jars/archives being built statically through the ant build files (or other tools). So if a project was doing this:

1) Build static jars (Ant scripts) as a separate step
2) Run tests which expect the archives/artifacts to be available on the file system

With the use of ShrinkWrap, the #1 could be completely gone and #2 would assemble the archive dynamically. And if there was an API which could export this dynamically generated archive to the file system, then the rest of the tests could continue to work without having to change to work against ShrinkWrap "Archives". Well, the clients could themselves write a simple util (which really is nothing more than a few lines) which writes out to the filesystem once the Archive is assembled, but i guess almost all clients would at some point of time require such functionality :-)

I guess i am thinking outside the lines of the Archive being used for deploying to some server. In the context of ShrinkWrap being used to create Archives for deploying to the server, the links that you pointed to, are better alternatives.

"ALRubinger" wrote:

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.

I see what you are saying. I haven't actually completely looked at the code/goals of ShrinkWrap, but isn't it already doing some of the IO related stuff? I might be wrong though :-) And yes, i do agree that it's a matter of finding the right place for this API.

[alrubinger]

I'm beginning to rethink the "flush to a file" util. Will sleep on it and we can rap tomorrow.

S,
ALR

[alrubinger]

Bah, but then again, there's no such thing as:

URL.saveAs(File);
InputStream.saveAs(File);
ByteArray.saveAs(File)

...so why would we? :)

S,
ALR

[johnbailey]

I agree. Every project I have ever worked on had some standard way to write an InputStream to a file. We could add it, but it it seems better to leave it up to the caller to use whatever mechanism they generally use to do so.

Then again, it is 5 lines of code to write the method, so if it can be added without confusing the interface. Maybe it could be added.

[alrubinger]

https://jira.jboss.org/jira/browse/SHRINKWRAP-87

S,

ALR