[
https://issues.apache.org/jira/browse/KAFKA-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584535#comment-13584535
]
Dave DeMaagd commented on KAFKA-733:
------------------------------------
The mergeStrategy was put in place because there was a conflict with zkclient:
java.lang.RuntimeException: deduplicate: different file contents found in the
following:
/...../.ivy2/cache/com.github.sgroschupf/zkclient/jars/zkclient-0.1.jar:org/I0Itec/zkclient/util/ZkPathUtil.class
/...../kafka-git/0.8/core/lib/zkclient-20120522.jar:org/I0Itec/zkclient/util/ZkPathUtil.class
The reason I chose 'MergeStrategy.last' was mostly a coin toss. If there is a
better argument (any sound reasoning is likely to trump my coin toss here), I
welcome suggestions to make this cover more cases than I had in mind.
I didn't add a main class to it because the the goal I had in mind was being
able to run the tools and admin bits without needing to cart around (and keep
track of for upgrades) a large number of files. A single jar file to track is
far easier from an operability standpoint for me to manage.
> Fat jar option for build, or override for ivy cache location
> -------------------------------------------------------------
>
> Key: KAFKA-733
> URL: https://issues.apache.org/jira/browse/KAFKA-733
> Project: Kafka
> Issue Type: Improvement
> Components: packaging
> Affects Versions: 0.8
> Reporter: Dave DeMaagd
> Assignee: Dave DeMaagd
> Labels: bugs
> Attachments: KAFKA-733.patch
>
>
> Need some kind of self-contained mechanism for running kafka to get around
> the following:
> 1) The location of the source checkout/build is not necessarily the same
> place where it will be running (the build location and that user's ivy cache
> dir) potentially leading to sync problems (forgetting the ivy dir) or just
> adding overhead to the deployment process (additional steps to remember
> introduces more chances for mistakes)
> 2) The user running the kafka service in a production setting may not even
> have a real home directory
> Think something like a 'fat jar' packaging (something that contains all
> necessary jar versions in one convenient place) would simplify deployment and
> reduce the chance for error (only one lib package to worry about, and it
> contains everything needed) and would be a little more production friendly
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
