This message was deleted.

That's an interesting thought. So it would be like a partial implementation of Automation API then, because it would only be able to do local programs?

I don't believe we have a roadmap item for this at the moment 😞

@bored-oyster-3147 given the Automation API still calls the pulumi CLI, can you elaborate on your statement

only be able to do local programs

? What is meant with

local

in this case?

Automation API has currently defined 3 different kinds of pulumi programs: • local: when you point Automation API at a directory that contains an existing pulumi project • inline: when you give Automation API infrastructure code directly (and your infrastructure code is executed in-process) • remote: when you point Automation API at a remote repository containing an existing pulumi project So if you implemented Automation API in Java such a way that you couldn't write infrastructure code in Java, you would not be able to do

inline

programs.

@bored-oyster-3147 clear. For my use case, I do not have a need for

inline

programs, which means I could live with this limitation. Adding to this, we will mainly have the

local

setup.

I don't do Java really but I don't think this would be very difficult. Most of the Automation API complexity comes from supporting

inline

programs. A partial Automation API implementation for Java would only need the parts that call out to the CLI

As @billowy-army-68599 mentioned, Java support is not currently on the roadmap. Would you be willing to file an issue in https://github.com/pulumi/pulumi/issues so other folks can upvote?

@flaky-ghost-73674 we do have an issue for it https://github.com/pulumi/pulumi/issues/1539

Ah, that one is for general Java support. The Automation API distinction is a good one, and worth a separate issue IMO.

-👍

This is something I've thought about. Altering the approach of automation API to rely on gRPC to make it easier to roll out support for non-core languages: https://github.com/pulumi/pulumi/issues/7220