Sounds good. The only thing I wanted to check first is if maybe we wanted to create a camel-compression component (containing the existing GzipDataFormat and ZipDataFormat, plus the new ZipFileDataFormat) or if the long-term goal is to have three different components (camel-zip, camel-zipfile, camel-gzip) -- in which case just creating the camel-zipfile component would be the best option.
-----Original Message----- From: Henryk Konsek [mailto:[email protected]] Sent: Thursday, February 14, 2013 11:44 AM To: [email protected] Subject: Re: Support for zip (de)compression > I have no idea what an enhancement to allow it to handle > multi-file Zips would look like :-) In the future we could support passing collection (maps in particular) of objects as a message to support nested directory hierarchies. But for the first version of this data format single-file-zip is fine, as this is pretty common use case for IT systems to generate files like this. We will create separated Maven module for your data format to keep camel-core as small as possible. Let's give it some nice artifactId like camel-zipfile. Please move the data format itself there and keep DSL in camel-core. Would you be so kind and apply appropriate changes to the patch? Thank you in advance. -- Henryk Konsek http://henryk-konsek.blogspot.com
