7 Replies Latest reply on Dec 22, 2009 10:05 AM by alrubinger

    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?


        • 1. Re: ShrinkWrap Export to File
          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


          • 2. Re: ShrinkWrap Export to File
            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

            • 3. Re: ShrinkWrap Export to File
              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.



              • 4. Re: ShrinkWrap Export to File
                alrubinger

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

                S,
                ALR

                • 5. Re: ShrinkWrap Export to File
                  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

                  • 6. Re: ShrinkWrap Export to File
                    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.

                    • 7. Re: ShrinkWrap Export to File
                      alrubinger