Adding a classpath check to scan for akka artifacts

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

Akka already has checks to make sure users don't mix and match
different artifacts on the class path. There is undergoing work in Pekko to
remove/fix these checks (i.e. see
https://github.com/apache/incubator-pekko/pull/189) however it does bring a
general point about whether we should check if there are any Akka artifacts
on the classpath for users running Pekko and produce warnings in such a
case.

I would predict that generally speaking if you are mixing Pekko and Akka
artifacts then this is likely a mistake and you are doing something wrong
even though technically speaking with all of the class/package/conf changes
there shouldn't be any conflicts (basically both ecosystems would sit in
their own silos).

Thoughts?
-- 

Matthew de Detrich

*Aiven Deutschland GmbH*

Immanuelkirchstraße 26, 10405 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

*m:* +491603708037

*w:* aiven.io *e:* matthew.dedetrich@aiven.io

Re: Adding a classpath check to scan for akka artifacts

[Johannes Rudolph <jo...@gmail.com>]

On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> general point about whether we should check if there are any Akka artifacts
> on the classpath for users running Pekko and produce warnings in such a
> case.

I don't think we should check that and assume both are silos.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Adding a classpath check to scan for akka artifacts

[Johannes Rudolph <jo...@gmail.com>]

On Wed, Feb 15, 2023 at 4:30 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> Regarding making Pekko automatically handle Akka configuration, I have
> doubts as to whether this feature provides as much benefit as is implied.

I agree, I found it some appealing in the beginning but what would
even be the benefit? If a user has already fixed all the imports in
the code it does seem rather minor to also requiring to update the
configuration settings...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Adding a classpath check to scan for akka artifacts

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

> Supporting users who want to have mixed Akka and Pekko clusters -
testing that will be hard. If anyone truly needs that then I think we
will need dedicated extra resources for this work. With the current
community size, it is hard to see us spending a lot of effort on this
- or we will seriously delay a v1.0.0 release.

Take this with a grain of salt because I don't have a lot of experience
here, but I don't think that supporting mixed cluster setups are
technically difficult if we do the remote wire incompatibility changes
(i.e. https://github.com/apache/incubator-pekko/issues/108). The biggest
issue here is actually testing it, irrc there was some mixed cluster tests
that are not running right now that also (before pekko) also had
reliability issues.

I would imagine that if someone was willing to test these mixed cluster
cases and/or get these mixed cluster tests working then its not
insurmountable barring that it does seem wise to not delay the release
because of this.

On Wed, Feb 15, 2023 at 4:58 PM PJ Fanning <fa...@apache.org> wrote:

> My preference is to update all 'akka' anything in Pekko code to
> 'pekko'. This breaks compatibility but is cleaner (IMHO).
>
> Documenting and ideally, automating migrations from Akka to Pekko is
> the way forward.
>
> Having Pekko code log warnings if it detects Akka on the classpath -
> this is probably prudent. If we get news from users, that having both
> libs on the classpath is not working, we may need to consider making
> Pekko refuse to start. I do see a use case where someone wants to read
> a message from an Akka actor instance and then forward it to a Pekko
> actor instance.
>
> Supporting users who want to have mixed Akka and Pekko clusters -
> testing that will be hard. If anyone truly needs that then I think we
> will need dedicated extra resources for this work. With the current
> community size, it is hard to see us spending a lot of effort on this
> - or we will seriously delay a v1.0.0 release.
>
> On Wed, 15 Feb 2023 at 16:30, Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > Regarding making Pekko automatically handle Akka configuration, I have
> > doubts as to whether this feature provides as much benefit as is implied.
> > Configuration tends to be static and I have the impression that a far
> nicer
> > solution to the problem would be to write a script that generates any
> > existing akka config to pekko config rather than making pekko handle akka
> > config
> >
> > On Wed, Feb 15, 2023 at 4:27 PM Jean-Luc Deprez <
> JeanLuc.Deprez@gmail.com>
> > wrote:
> >
> > > The moment that the "can also parse akka HOCON prefix compat"-feature
> gets
> > > introduced things can turn rapidly sour though.
> > >
> > > Having both in a single JVM/Classloader tree structure is doubtedly
> part of
> > > any future ideal, but I a straight line towards that ideal could be
> wishful
> > > thinking.
> > > Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding
> the
> > > duo)
> > >
> > > On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > >
> > > > Akka already has checks to make sure users don't mix and match
> > > > different artifacts on the class path. There is undergoing work in
> Pekko
> > > to
> > > > remove/fix these checks (i.e. see
> > > > https://github.com/apache/incubator-pekko/pull/189) however it does
> > > bring
> > > > a
> > > > general point about whether we should check if there are any Akka
> > > artifacts
> > > > on the classpath for users running Pekko and produce warnings in
> such a
> > > > case.
> > > >
> > > > I would predict that generally speaking if you are mixing Pekko and
> Akka
> > > > artifacts then this is likely a mistake and you are doing something
> wrong
> > > > even though technically speaking with all of the class/package/conf
> > > changes
> > > > there shouldn't be any conflicts (basically both ecosystems would
> sit in
> > > > their own silos).
> > > >
> > > > Thoughts?
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

Matthew de Detrich

*Aiven Deutschland GmbH*

Immanuelkirchstraße 26, 10405 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

*m:* +491603708037

*w:* aiven.io *e:* matthew.dedetrich@aiven.io

Re: Adding a classpath check to scan for akka artifacts

[PJ Fanning <fa...@apache.org>]

My preference is to update all 'akka' anything in Pekko code to
'pekko'. This breaks compatibility but is cleaner (IMHO).

Documenting and ideally, automating migrations from Akka to Pekko is
the way forward.

Having Pekko code log warnings if it detects Akka on the classpath -
this is probably prudent. If we get news from users, that having both
libs on the classpath is not working, we may need to consider making
Pekko refuse to start. I do see a use case where someone wants to read
a message from an Akka actor instance and then forward it to a Pekko
actor instance.

Supporting users who want to have mixed Akka and Pekko clusters -
testing that will be hard. If anyone truly needs that then I think we
will need dedicated extra resources for this work. With the current
community size, it is hard to see us spending a lot of effort on this
- or we will seriously delay a v1.0.0 release.

On Wed, 15 Feb 2023 at 16:30, Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
>
> Regarding making Pekko automatically handle Akka configuration, I have
> doubts as to whether this feature provides as much benefit as is implied.
> Configuration tends to be static and I have the impression that a far nicer
> solution to the problem would be to write a script that generates any
> existing akka config to pekko config rather than making pekko handle akka
> config
>
> On Wed, Feb 15, 2023 at 4:27 PM Jean-Luc Deprez <Je...@gmail.com>
> wrote:
>
> > The moment that the "can also parse akka HOCON prefix compat"-feature gets
> > introduced things can turn rapidly sour though.
> >
> > Having both in a single JVM/Classloader tree structure is doubtedly part of
> > any future ideal, but I a straight line towards that ideal could be wishful
> > thinking.
> > Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding the
> > duo)
> >
> > On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> >
> > > Akka already has checks to make sure users don't mix and match
> > > different artifacts on the class path. There is undergoing work in Pekko
> > to
> > > remove/fix these checks (i.e. see
> > > https://github.com/apache/incubator-pekko/pull/189) however it does
> > bring
> > > a
> > > general point about whether we should check if there are any Akka
> > artifacts
> > > on the classpath for users running Pekko and produce warnings in such a
> > > case.
> > >
> > > I would predict that generally speaking if you are mixing Pekko and Akka
> > > artifacts then this is likely a mistake and you are doing something wrong
> > > even though technically speaking with all of the class/package/conf
> > changes
> > > there shouldn't be any conflicts (basically both ecosystems would sit in
> > > their own silos).
> > >
> > > Thoughts?
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Adding a classpath check to scan for akka artifacts

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

Regarding making Pekko automatically handle Akka configuration, I have
doubts as to whether this feature provides as much benefit as is implied.
Configuration tends to be static and I have the impression that a far nicer
solution to the problem would be to write a script that generates any
existing akka config to pekko config rather than making pekko handle akka
config

On Wed, Feb 15, 2023 at 4:27 PM Jean-Luc Deprez <Je...@gmail.com>
wrote:

> The moment that the "can also parse akka HOCON prefix compat"-feature gets
> introduced things can turn rapidly sour though.
>
> Having both in a single JVM/Classloader tree structure is doubtedly part of
> any future ideal, but I a straight line towards that ideal could be wishful
> thinking.
> Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding the
> duo)
>
> On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > Akka already has checks to make sure users don't mix and match
> > different artifacts on the class path. There is undergoing work in Pekko
> to
> > remove/fix these checks (i.e. see
> > https://github.com/apache/incubator-pekko/pull/189) however it does
> bring
> > a
> > general point about whether we should check if there are any Akka
> artifacts
> > on the classpath for users running Pekko and produce warnings in such a
> > case.
> >
> > I would predict that generally speaking if you are mixing Pekko and Akka
> > artifacts then this is likely a mistake and you are doing something wrong
> > even though technically speaking with all of the class/package/conf
> changes
> > there shouldn't be any conflicts (basically both ecosystems would sit in
> > their own silos).
> >
> > Thoughts?
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>


-- 

Matthew de Detrich

*Aiven Deutschland GmbH*

Immanuelkirchstraße 26, 10405 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

*m:* +491603708037

*w:* aiven.io *e:* matthew.dedetrich@aiven.io

Re: Adding a classpath check to scan for akka artifacts

[Jean-Luc Deprez <Je...@gmail.com>]

The moment that the "can also parse akka HOCON prefix compat"-feature gets
introduced things can turn rapidly sour though.

Having both in a single JVM/Classloader tree structure is doubtedly part of
any future ideal, but I a straight line towards that ideal could be wishful
thinking.
Yet, I have sort of set my mind to doing exactly that 🤭 (so avoiding the
duo)

On Wed, Feb 15, 2023 at 3:33 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:

> Akka already has checks to make sure users don't mix and match
> different artifacts on the class path. There is undergoing work in Pekko to
> remove/fix these checks (i.e. see
> https://github.com/apache/incubator-pekko/pull/189) however it does bring
> a
> general point about whether we should check if there are any Akka artifacts
> on the classpath for users running Pekko and produce warnings in such a
> case.
>
> I would predict that generally speaking if you are mixing Pekko and Akka
> artifacts then this is likely a mistake and you are doing something wrong
> even though technically speaking with all of the class/package/conf changes
> there shouldn't be any conflicts (basically both ecosystems would sit in
> their own silos).
>
> Thoughts?
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>