Makes sense to me. Let's deprecate for the 2.52.0 release unless there is some objection. You can also look at the maven central downloads (I believe all PMC and maybe all committers can view this) compared to other Beam jars.
Kenn On Mon, Oct 16, 2023 at 9:28 AM Jan Lukavský <je...@seznam.cz> wrote: > Sure, that would be probably the preferred way to go. For now, I'm > trying to get some feedback, if there are some real-world users who > might miss the API. Currently, the only value I see is that Euphoria > adds an additional level of indirection for user code. The expansion > goes like this: > > Euphoria Pipeline -> runtime provided translators -> vanilla Beam > Pipeline -> runner > > Hence code written using Euphoria extension can be modified at runtime > (Pipeline construction time) using dependency injection, which brings > the value that users can modify (typically optimize) Pipelines without > actually modifying the business logic. On the other hand I'm not sure if > this justifies the complexity of the extension. Were this the only > value, it should be possible to implement such dynamic expansion either > into Java SDK core or as a different light-weight extension. > > Jan > > On 10/16/23 15:10, Alexey Romanenko wrote: > > Can we just deprecate it for a while and then remove completely? > > > > — > > Alexey > > > >> On 13 Oct 2023, at 18:59, Jan Lukavský <je...@seznam.cz> wrote: > >> > >> Hi, > >> > >> it has been some time since Euphoria extension [1] has been adopted by > Beam as a possible "Java 8 API". Beam has evolved from that time a lot, the > current API seems actually more elegant than the original Euphoria's and > last but not least, it has no maintainers and no known users. If there are > any users, please speak up! > >> > >> Otherwise I'd like to propose to drop it from codebase, I'll start a > vote thread during next week, if there are no objections. > >> > >> Best, > >> > >> Jan > >> > >> [1] https://beam.apache.org/documentation/sdks/java/euphoria/ > >> >
