You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Roshan Naik (JIRA)" <ji...@apache.org> on 2015/10/24 00:49:27 UTC
[jira] [Comment Edited] (FLUME-2819) Kafka libs are being bundled
into Flume distro
[ https://issues.apache.org/jira/browse/FLUME-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972022#comment-14972022 ]
Roshan Naik edited comment on FLUME-2819 at 10/23/15 10:49 PM:
---------------------------------------------------------------
- Flume depends on several external services (hadoop and non hadoop) and that list keeps growing with each release. So not feasible to keep updating and releasing Flume frequently (i.e each time one of them release a new version) to enable Flume users leverage new features being release in them.
- Releasing frequently with updated version creates a diff problem .. it ties each Flume version to a specific dep version. And in the end user may not want to use that version of the service.
- Release frequently model also forces Flume to release each time there is a security fix releases in them
- If users have to wait for new Flume releases, that then leads to long waits for users... or the need to perform surgery on the flume/lib directory. Neither is reasonable.
Consequently, IMO ... using the "provided" model for such deps and giving the users a mechanism to customize the Flume Classpath easily, is in the end a better choice. The slight OOB experience penalty is a smaller problem when considering all the trade offs.
was (Author: roshan_naik):
- Flume depends on several external services (hadoop and non hadoop) and that list keeps growing with each release. So not feasible to keep updating and releasing Flume frequently (i.e each time one of them release a new version) to enable Flume users leverage new features being release in them.
- Releasing frequently with updated version creates a diff problem .. it ties each Flume version to a specific dep version. And in the end user may not want to use that version of the service.
- Release frequently model also forces Flume to release each time there is a security fix releases in them
- If users have to wait for new Flume releases, that then leads to long waits for users... or the need to perform surgery on the flume/lib directory. Neither is reasonable.
Consequently, IMO, using the "provided" model for such deps and giving the users a mechanism to customize the Flume Classpath easily, is in the end a better choice.
> Kafka libs are being bundled into Flume distro
> ----------------------------------------------
>
> Key: FLUME-2819
> URL: https://issues.apache.org/jira/browse/FLUME-2819
> Project: Flume
> Issue Type: Bug
> Reporter: Roshan Naik
>
> Kafka dependency libs need to be marked as 'provided' in the pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)