> You can create multiple instances of the same coordinator class. Pass appropriate arguments to suite your need. This is in the AIP.
Yes. And you cand do exactly the same 1-1 if it's part of package and embedded in "airflow-sdk" distribution? Or am I wrong? Why do you think it would not be possible if it's part of task_sdk? On Wed, May 13, 2026 at 6:43 PM Tzu-ping Chung via dev < [email protected]> wrote: > You can create multiple instances of the same coordinator class. Pass > appropriate arguments to suite your need. This is in the AIP. > > [sdk] > coordinators = { > "jdk-11": { > "classpath": "airflow.sdk.coordinators.java.JavaCoordinator", > "kwargs": {"java_executable": > "/usr/lib/jvm/java-11-openjdk/bin/java", "jars_root": ["/files/old/lib"]} > }, > "jdk-17": { > "classpath": "airflow.sdk.coordinators.java.JavaCoordinator", > "kwargs": {"java_executable": > "/usr/lib/jvm/java-17-openjdk/bin/java", "jars_root": ["/files/new/lib"], > "jvm_args": ["-Xmx1024m"]} > } > } > > The problem is, classpath points to a class, so whatever this string is > needs to be kept compatible in future releases. > > > > > On 13 May 2026, at 23:59, Jarek Potiuk <[email protected]> wrote: > > > > > How do you make it changeable any time? User needs to be able to > specify what coordinator to use in the config, and you can’t break that > later. > > We have only *jdk* coordinator now . So I will revert the question. How > are you going to configure two "jdk" `coordinators` when you have separate > distributions running "java"? Are you planning to install two > "coordinator-jdk" packages? This isn't possible in Python unless you build > almost the same package with jdk-11, jdk-19 built in? > > My understanding is that you will have configuration options to choose > between "jdk-11" and "jdk-19." This "jdk" package of yours will simply have > a list of "jdks" linking to the Java interpreters. > > > > So, it doesn't matter if it's a single "coordinator-jdk" package or > everything in "airflow.sdk._coordinator."jdk" package or > "airflow.sdk._bridge.jdk" package in the task-sdk. Regardless, you cannot > install two "jdk" packages, whether they are separate distributions or if > the package is in "task-sdk" and you have to configure which of the "jdk" > bridges you want to use. > > Yes. Sometime later, when we also have Go/TypeScript or other languages, > we might decide to centralize some APIs, create a "true" coordinator > package and separate distributions. And splitting into different packages > will be absolutely no problem then. Nothing will stop us from doing it. > > > > It will save a lot of time for all the "distribution" issue - including > releases, packagig, CI and everything connected - and it does not > absolutely block us from further split later. > > > > J. > > > > > > > > On Wed, May 13, 2026 at 3:47 PM Tzu-ping Chung via dev < > [email protected] <mailto:[email protected]>> wrote: > >> > >> > >> > On 13 May 2026, at 20:42, Jarek Potiuk <[email protected] <mailto: > [email protected]>> wrote: > >> > > >> > Not really. I proposed an internal package that can be changed **any > time**. Users aren't supposed to use those items. We can clearly mark them > with "_" and also describe them thoroughly in the public API documentation. > And no. Initilaly providers were **not** in arflow at all - you started > from step 2. Step 1 is that they were added at some point in time long > before my time. Hooks and operators as "API" were creaed quite early in the > concept of Airflow - and the first implementations were added then. Then, > after common patterns emerged, those hooks and operators were grouped into > providers (they were not initially) and only moved out after quite some > time. As I see it - you even admit yourself that things will look > differently for different languages, and maybe even we will not need > bridges for some of them at all. So why should we introduce new concept if > we know currrently that it applies only to "JDK"? I fail to see why we > should proceed if we already know the patterns are unlikely to be reusable > in their current form. > >> > >> How do you make it changeable any time? User needs to be able to > specify what coordinator to use in the config, and you can’t break that > later. > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] <mailto: > [email protected]> > >> For additional commands, e-mail: [email protected] <mailto: > [email protected]> > >> > >
