+1 on arranging module names on storm-kafka and storm-kafka-client (with versions).
Actually there's another trick behind storm-kafka-client. storm-kafka-client 1.0.x supports Kafka 0.9.x and storm-kafka-client 1.1.0 (SNAPSHOT) supports Kafka 0.10.x, which can make a confusion. There was also a question from mailing list regarding this. The thing is how we name the module based on support version (naming convention). 2016년 9월 21일 (수) 오전 8:48, P. Taylor Goetz <[email protected]>님이 작성: > Now might be a time to consider making version-sensitive modules ((kafk, > ES) maven multi-modules. > > I've never really liked "storm-Kafka" and "storm-kafka-client" as > differentiators of Kafka 0.9..X and 0.10.x. I'd tend toward something like: > > storm-Kafka/ > /0.9.x > /0.10.x > > I would think the same thing would apply to ES. > > I'm +1 for supporting both versions, with careful consideration wrt how > and when to deprecate or EOL support for a version line. > > -Taylor > > > On Sep 20, 2016, at 7:30 PM, Aaron Niskodé-Dossett <[email protected]> > wrote: > > > > Thanks everyone. Could one or more committers +1 the PR that would > support > > both versions? > > > > https://github.com/apache/storm/pull/1337 > > On Mon, Sep 19, 2016 at 10:52 AM Satish Duggana < > [email protected]> > > wrote: > > > >> Agree with Bobby, +1 for supporting both versions till EOL and findout > how > >> many users are really using 1.7.x. > >> > >> ~Satish. > >> > >> > >> On Mon, Sep 19, 2016 at 7:50 PM, Bobby Evans > <[email protected]> > >> wrote: > >> > >>> I am +1 for two modules until EOL. Jan 2017. - Bobby > >>> > >>> On Saturday, September 17, 2016 4:19 AM, Jungtaek Lim < > >>> [email protected]> wrote: > >>> > >>> > >>> According to the link, last version line of ES1 (1.7.x) will be live to > >>> Jan > >>> 2017. We need to keep two versions at least EOL of that. > >>> I wouldn't mind having two modules and also wouldn't mind having > >> duplicate > >>> codes, but it would be better if we can extract common parts to parent > >>> module. > >>> > >>> Thanks, > >>> Jungtaek Lim (HeartSaVioR) > >>> > >>> 2016년 9월 16일 (금) 오후 10:03, Aaron Niskodé-Dossett <[email protected]>님이 > >> 작성: > >>> > >>>> ES1 is close to end of life in terms of commercial support from > >> Elastic, > >>>> but not quite there (https://www.elastic.co/support/eol). > >> Unfortunately > >>>> the ES1 and ES2 clients won't interoperate with their opposite > >> versions. > >>>> > >>>> Given that, I take it you would support having ES1 and ES2 bolts > >> packaged > >>>> separately? This would somewhat like how we have storm-kafka and > >>>> storm-kafka-client for different Kafka versions. > >>>> > >>>> Thanks! -Aaron > >>>> > >>>> On Thu, Sep 15, 2016 at 9:12 AM Bobby Evans > >> <[email protected] > >>>> > >>>> wrote: > >>>> > >>>>> I personally don't use ES as part of my storm work, so I don't > >>>> necessarily > >>>>> feel qualified to answer this. In general though I really do like to > >>> see > >>>>> storm come with batteries included. If ES1 is not end of life, and > >>> there > >>>>> is a community of people who want to continue using it/supporting > >> it, I > >>>>> would say lets continue to do so. If that is not true, or if ES > >>> offers a > >>>>> backwards compatible client that could sway things for me to say lets > >>>> just > >>>>> go forward with ES2. - Bobby > >>>>> > >>>>> On Wednesday, September 14, 2016 2:47 PM, Aaron Niskodé-Dossett < > >>>>> [email protected]> wrote: > >>>>> > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I started a a discussion about this a while ago, but didn't take it > >> to > >>> a > >>>>> conclusion (my $realjob, etc., etc.). > >>>>> > >>>>> There are multiple PRs open to provide an Elastic Search 2.x bolt to > >>> the > >>>>> Storm project. There are two different approaches: > >>>>> > >>>>> 1. Add side-by-side support for 2.x. Example: > >>>>> https://github.com/apache/storm/pull/1337 (*FULL DISCLOSURE*: this > >> is > >>> my > >>>>> own PR). [I also have some functionality enhancements in this PR, but > >>>>> that's not relevant to this discussion.] > >>>>> > >>>>> 2. Upgrade existing bolt. Example, > >>>>> https://github.com/apache/storm/pull/1396 > >>>>> > >>>>> The drawback to approach 1 is that it duplicates a lot of code. The > >>>>> drawback to approach 2 is that it drops support for ES 1.x. > >>>>> > >>>>> ES 2.X has been out for a while and if we are serious about > >> supporting > >>>> it, > >>>>> we need to have a way to write to ES 2.X. > >>>>> > >>>>> I believe approach number 1 is ideal (again, it's my own PR) and > >>> possibly > >>>>> deprecating the existing 1.X bolt. > >>>>> > >>>>> I'd love to hear thoughts from others! > >> >
