> Camel provides a pluggable data format so we can have implementations
> outside the camel-core
>
> But a selected few do not depend on 3rd party .jars which of course
> allow us to host the implementations directly in camel-core.

> Cool if you want to help then please take a look and see what you
> think needs to be done.

I just looked at it. Following your explaination with dependencies and
looking at c-cores pom, I think that the ZipDataFormat needs to be
extracted as a plugable implementation.

If one would do this, we could do this also for GZipDataFormat which
also is cared of by Compress.

Same goes with ar, cpio, tar and bzip2 which could mean that the
camel-compress component could support various additional formats
which are not supported at the moment (or so it seems to me).

The ZipDataFormat and the GZipDataFormat looks quite forward to me. I
think with compress it's the same amount of source lines.

To guarantee backwards compatibility the current Zip-Impl should be
deprecated but enhanced with Vladimirs suggestions.

Wdyt?

Cheers
Christian

Reply via email to