A little after 72h have passed I'm happy to announce that this KIP has been accepted.
Additionally, since all votes were submitted within the KIP deadline for KIPs targeting the 0.11.0.0 release, I intend to publish an implementation for review, targeting the forthcoming Apache Kafka release. Here are the votes: +1s (binding): 5 - Guozhang Wang, Sriram Subramanian, Ismael Juma, Gwen Shapira, Ewen Cheslack-Postava +1s (non-binding): 3 - Stephane Maarek, Dan Norwood, Colin McCabe -1s: 0 Thanks to everyone who reviewed and commented on this KIP. -Konstantine On Wed, May 10, 2017 at 9:54 PM, Konstantine Karantasis < konstant...@confluent.io> wrote: > The KIP description has been updated to reflect the use of the term > plugin.path instead. > > -Konstantine > > > > > On Wed, May 10, 2017 at 2:10 PM, Ismael Juma <ism...@juma.me.uk> wrote: > >> Konstantine, I am not convinced that it will represent similar >> functionality as the goals are different. Also, I don't see a migration >> path. To use Jigsaw, it makes sense to configure the module path during >> start-up (-mp) like one configures the classpath. Whatever we are >> implementing in Connect will be its own thing and it will be with us for >> many years. >> >> Ewen, as far as the JVM goes, I think `module.path` is probably the name >> most likely to create confusion since it refers to a concept that was >> recently introduced, has very specific (and some would say unexpected) >> behaviour and it will be supported by java/javac launchers, build tools, >> etc. >> >> Gwen, `plugin.path` sounds good to me. >> >> In any case, I will leave it to you all to decide. :) >> >> Ismael >> >> On Wed, May 10, 2017 at 8:11 PM, Konstantine Karantasis < >> konstant...@confluent.io> wrote: >> >> > Thank you Ismael for your vote as well as your comment. >> > >> > To give some context, it's exactly because of the similarities with >> Jigsaw >> > that module.path was selected initially. >> > The thought was that it could allow for a potential integration with >> Jigsaw >> > in the future, without having to change property names significantly. >> > >> > Of course there are differences, as the ones you mention, mainly because >> > Connect's module path currently is composed as a list of top-level >> > directories that include the modules as subdirectories. However I'd be >> > inclined to agree with Ewen. Maybe using a property name that presents >> > similarities to other concepts in the JVM ecosystem reserves for us more >> > flexibility than using a different name for something that will >> eventually >> > end up representing similar functionality. >> > >> > In any case, I don't feel very strong about it. Let me know if you >> insist >> > on a name change. >> > >> > -Konstantine >> > >> > >> > On Wed, May 10, 2017 at 10:24 AM, Ewen Cheslack-Postava < >> e...@confluent.io >> > > >> > wrote: >> > >> > > +1 binding, and I'm flexible on the config name. Somehow I am >> guessing no >> > > matter what terminology we use there somebody will find a way to be >> > > confused. >> > > >> > > -Ewen >> > > >> > > On Wed, May 10, 2017 at 9:27 AM, Gwen Shapira <g...@confluent.io> >> wrote: >> > > >> > > > +1 and proposing 'plugin.path' as we use the term connector plugins >> > when >> > > > referring to the jars themselves. >> > > > >> > > > Gwen >> > > > >> > > > On Wed, May 10, 2017 at 8:31 AM, Ismael Juma <ism...@juma.me.uk> >> > wrote: >> > > > >> > > > > Thanks for the KIP Konstantine, +1 (binding) from me. One comment; >> > > > > >> > > > > 1. One thing to think about: the config name `module.path` could >> be >> > > > > confusing in the future as Jigsaw introduces the concept of a >> module >> > > > > path[1] in Java 9. The module path co-exists with the classpath, >> but >> > > its >> > > > > behaviour is quite different. To many people's surprise, Jigsaw >> > doesn't >> > > > > handle versioning and it disallows split packages (i.e. if the >> same >> > > > package >> > > > > appears in 2 different modules, it is an error). What we are >> > proposing >> > > is >> > > > > quite different and perhaps it may make sense to use a different >> name >> > > to >> > > > > avoid confusion. >> > > > > >> > > > > Ismael >> > > > > >> > > > > [1] https://www.infoq.com/articles/Latest-Project- >> > > Jigsaw-Usage-Tutorial >> > > > > >> > > > > On Mon, May 8, 2017 at 7:48 PM, Konstantine Karantasis < >> > > > > konstant...@confluent.io> wrote: >> > > > > >> > > > > > ** Restarting the voting thread here, with a different title to >> > avoid >> > > > > > collapsing this thread's messages with the discussion thread's >> > > messages >> > > > > in >> > > > > > mail clients. Apologies for the inconvenience. ** >> > > > > > >> > > > > > >> > > > > > Hi all, >> > > > > > >> > > > > > Given that the comments during the discussion seem to have been >> > > > > addressed, >> > > > > > I'm pleased to bring >> > > > > > >> > > > > > KIP-146: Classloading Isolation in Connect >> > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> > > > > > 146+-+Classloading+Isolation+in+Connect >> > > > > > >> > > > > > up for voting. Again, this KIP aims to bring the highly desired >> > > feature >> > > > > of >> > > > > > dependency isolation in Kafka Connect. >> > > > > > >> > > > > > In the meantime, for any additional feedback, please continue to >> > send >> > > > > your >> > > > > > comments in the discussion thread here: >> > > > > > >> > > > > > https://www.mail-archive.com/dev@kafka.apache.org/msg71453.html >> > > > > > >> > > > > > This voting thread will stay active for a minimum of 72 hours. >> > > > > > >> > > > > > Sincerely, >> > > > > > Konstantine >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > *Gwen Shapira* >> > > > Product Manager | Confluent >> > > > 650.450.2760 | @gwenshap >> > > > Follow us: Twitter <https://twitter.com/ConfluentInc> | blog >> > > > <http://www.confluent.io/blog> >> > > > >> > > >> > >> > >
