You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Konstantine Karantasis <ko...@confluent.io> on 2017/05/08 18:48:09 UTC
[VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
** 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
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Konstantine Karantasis <ko...@confluent.io>.
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 <
konstantine@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 <is...@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 <
>> konstantine@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 <
>> ewen@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 <gw...@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 <is...@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 <
>> > > > > konstantine@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>
>> > > >
>> > >
>> >
>>
>
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Konstantine Karantasis <ko...@confluent.io>.
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 <is...@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 <
> konstantine@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 <
> ewen@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 <gw...@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 <is...@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 <
> > > > > konstantine@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>
> > > >
> > >
> >
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Ismael Juma <is...@juma.me.uk>.
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 <
konstantine@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 <ewen@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 <gw...@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 <is...@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 <
> > > > konstantine@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>
> > >
> >
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Konstantine Karantasis <ko...@confluent.io>.
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 <ew...@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 <gw...@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 <is...@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 <
> > > konstantine@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>
> >
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Ewen Cheslack-Postava <ew...@confluent.io>.
+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 <gw...@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 <is...@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 <
> > konstantine@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>
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Gwen Shapira <gw...@confluent.io>.
+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 <is...@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 <
> konstantine@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>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Ismael Juma <is...@juma.me.uk>.
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 <
konstantine@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
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Sriram Subramanian <ra...@confluent.io>.
+1
On Tue, May 9, 2017 at 9:43 PM, dan <da...@gmail.com> wrote:
> +1 (non binding)
>
> thanks Konstantine :thumbsup:
>
> On Mon, May 8, 2017 at 3:24 PM, Guozhang Wang <wa...@gmail.com> wrote:
>
> > +1
> >
> > On Mon, May 8, 2017 at 1:36 PM, Stephane Maarek <
> > stephane@simplemachines.com.au> wrote:
> >
> > > +1
> > > Thanks heaps I can’t wait!
> > >
> > >
> > > On 9/5/17, 4:48 am, "Konstantine Karantasis" <konstantine@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
> > >
> > >
> > >
> > >
> >
> >
> > --
> > -- Guozhang
> >
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by dan <da...@gmail.com>.
+1 (non binding)
thanks Konstantine :thumbsup:
On Mon, May 8, 2017 at 3:24 PM, Guozhang Wang <wa...@gmail.com> wrote:
> +1
>
> On Mon, May 8, 2017 at 1:36 PM, Stephane Maarek <
> stephane@simplemachines.com.au> wrote:
>
> > +1
> > Thanks heaps I can’t wait!
> >
> >
> > On 9/5/17, 4:48 am, "Konstantine Karantasis" <ko...@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
> >
> >
> >
> >
>
>
> --
> -- Guozhang
>
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Guozhang Wang <wa...@gmail.com>.
+1
On Mon, May 8, 2017 at 1:36 PM, Stephane Maarek <
stephane@simplemachines.com.au> wrote:
> +1
> Thanks heaps I can’t wait!
>
>
> On 9/5/17, 4:48 am, "Konstantine Karantasis" <ko...@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
>
>
>
>
--
-- Guozhang
Re: [VOTE] KIP-146: Isolation of dependencies and classes in Kafka
Connect (restarted voting thread)
Posted by Stephane Maarek <st...@simplemachines.com.au>.
+1
Thanks heaps I can’t wait!
On 9/5/17, 4:48 am, "Konstantine Karantasis" <ko...@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