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