ZipExporter creating incorrect jar archive

[sbunciak]

Hi,

I'm trying to implement my own Container Adapter, and I'm having troubles with ZipExporter.

this snippet:

archive.as(ZipExporter.class).exportTo(new File("/home/sbunciak/s-ramp-exporter.jar"), true);

processing following ShrinkWrap archive

@Deployment
    public static Archive<?> createDeployment() {
        JavaArchive archive = ShrinkWrap
                .create(JavaArchive.class, "sramp-test.jar")
                .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
                .addAsManifestResource("switchyard.xml");
        return archive;
    }

produced in ShrinkWrap 1.0.1 (included in Arquillian BOM 1.0.4.Final) zip file with the following structure:

" zip.vim version v27
" Browsing zipfile /home/sbunciak/s-ramp-exporter.jar
" Select a file with cursor and press ENTER

META-INF/
META-INF/switchyard.xml
META-INF/beans.xml
org/
org/jboss/
org/jboss/arquillian/
org/jboss/arquillian/container/
org/jboss/arquillian/container/sramp/
org/jboss/arquillian/container/sramp/DeploymentTest.class

however, a newer version  (since Arquillian BOM 1.1.0.Final with ShrinkWrap 1.1.2) produced zip file like this:

" zip.vim version v27
" Browsing zipfile /home/sbunciak/s-ramp-resource.jar
" Select a file with cursor and press ENTER

META-INF/switchyard.xml
org/jboss/
META-INF/beans.xml
org/jboss/arquillian/container/
org/jboss/arquillian/container/sramp/DeploymentTest.class
org/jboss/arquillian/container/sramp/
META-INF/
org/jboss/arquillian/
org/

Is this some side effect of https://issues.jboss.org/browse/SHRINKWRAP-434 ? I need Zip archive entries in correct order for further processing, so I had to revert to Arquillian BOM 1.0.4. (containing ShrinkWrap 1.0.1)

Any suggestions how to use newer version of ShrinkWrap? Should I file a bug?

Thanks

[kpiwko]

Hi Stefan,

what you mean by further processing? Are you processing resulting jar by some external tools or within the container? If it's within Java code, you should be able to iterate directly on top the archive nodes/assets, so order should be irrelevant.

You can use dependencyManagement to override shrinkwrap version - by importing shrinkwrap-bom before, arquillian-bom, however using latest Arquillian without latest ShrinkWrap might not work as expected.

Please file a bug in SHRINKWRAP jira if you need to enforce a specific order in zip.

Karel

[sbunciak]

By further processing I mean that content of this Zip is processed by 3rd party library. This library relies on correct order of entries in the Zip file, as it tries to create directories from zip sequentially, as they are stored in the Zip file. Once it hits a directory which is already created (e.g. because a sub folder was already created in previous step) the whole processing fails. I'll contact developer of that library if he can implement support also for "unordered" zip files.

I also filed a new feature request to consider: [SHRINKWRAP-480] Fix order of entries in exported zip file - JBoss Issue Tracker

Thanks for help!