kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave DeMaagd (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-733) Fat jar option for build, or override for ivy cache location
Date Fri, 22 Feb 2013 18:46:14 GMT

    [ 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:

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

View raw message