Large Sonic Connect Archive: csar ... and Subversion

Posted by sedge on 13-Mar-2011 22:28

I have a Sonic 8.0.1 development going which is made up of several Sonic Connect projects, and Team Synchronisation with Subversion.

In one project the .csar file is 62 MB (all the others are < 1 MB). It takes a long time to commit over a remote connection.

1) How come the CSAR file is so big?

2) Can it be made smaller?

2) Is it a critical file to the project?

     - Can t be safely deleted?

     - Can it be ignored in Subversion (so that a checkout of the project would stiull work)?

Thanks

Steve

Technology Partner - Forum

All Replies

Posted by tsteinbo on 15-Mar-2011 05:33

Steve,

the reason the csar is so large is that for simplicity we do package the entire project into it. If you open this (zip) file you will immediately see what I mean. The csar (and the properties file) is a required deployment artefact but you can force a rebuild by performning an upload all from Workbench. To avoid the rebuild it might be better to version control the file after all.

But to give you some more guidance for your decision here is some more background about the required inner structure and content     of a csar:

The minimal csar must contain the esbcamel files (see     .services/), the spring.xml (see config/). The files can be anywhere     within the zip but to be found must have the .esbcamel extension and     be named spring.xml respectively.

If you are exposing POJO you need to add any compiled java classes     as jars (see lib/).

For the WebService case WSDLs should be included in the csar, but     technically you can point to any URLs (e.g.     http://server:port/service?wsdl). The recommendation though would be     to include them into the csar and reference them with relative     paths, e.g. resources/wsdl/my.wsdl. The inner directory structure of     the csar matters in this case.

Hope this helps

Thomas

Posted by sedge on 15-Mar-2011 17:24

Thanks for the heads-up Thomas.

Armed with the knowledge that the CSAR is a ZIP I investigated a bit further.

What I see is that you are also packaging the .svn (Subversion) folder in the CSAR. This changes the CSAR every time anything in the project changes, making the .svn that looks after the CSAR bigger. As more files get changed their .svn records increase, and the bigger the CSAR gets and the bigger the .svn that looks after the CSAR gets and the bigger the CSAR itself gets. An ever-growing file.

SInce I made this post my CSAR increased from 62 MB to 71 MB. I hadn't added any new files, just done some refactoring; renaming of packages and the like.

What I found in the CSAR was:

- The Unzipped size is 79 MB

- The lib fiolder is 78 MB

- The lib folder contents are two jars, totalling under 6 MB

- The lib\.svn folder is 73 MB

- File lib\.svn\text-base\myProject.csar.svn-base is 68 MB

Two suggestions:

- Omit the Subversion folders (and any other source control ones) from the CSAR

- Rebuild the CSAR on loading the Workbench, if it isn't found.

I'd really appreciate a quick fix or work around for this or my development is going to grind to a halt. Over the last few days the workbench has been crashing with heap and memory issues with increasing regularity.

Regards

Steve

Posted by sedge on 15-Mar-2011 18:45

And here's the quick fix from the good guys at Progress Support

There is way to mention the list of files/folders to ignore (exclude) them into the .csar file when it is built and hence reduce the size of the .csar file.
Here is the file \Workbench8.0\eclipse\plugins\com.sonicsw.tools.sonicconnect_8.0.1\resrc\defaultArchiveFilter.properties to specify the ignore list.

Just add .svn to the excluded folders list.

Also, the .csar file is re-recreated when you do an "Upload All" for the project so it is safe to Ignore the .csar file in Subversion.

This thread is closed