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