pulumi-java-gen fills in default dependency versions that pulumi gen-sdk doesn't #1404
Assignees
Labels
area/codegen
kind/bug
Some behavior is incorrect or out of spec
resolution/fixed
This issue was fixed
Milestone
Comments
lunaris
added a commit
that referenced
this issue
Dec 19, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it). Closes #1404
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it) and #1508. Closes #1404 Fixes #1508
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it) and #1508. Closes #1404 Fixes #1508
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it). Closes #1404
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it), and #1508 Closes #1404 Fixes #1508
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it), and #1508 Closes #1404 Fixes #1508
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it), and #1508 Closes #1404 Fixes #1508
lunaris
added a commit
that referenced
this issue
Dec 20, 2024
Presently, the majority of Java code generation is driven by the `pulumi-java-gen` binary, since Java usage began before we had time to implement the `Generate*` family of language host gRPC methods. Recently, these gRPC methods were implemented, to support (among other things) conformance testing. Unfortunately, while both routes end in `pkg/codegen/java`'s `Generate*` functions, each had accumulated its own special "setup logic" ahead of the call into `pkg/codegen`. This commit attempts to sort this out, pushing all that logic into `pkg/codegen` so that both routes behave identically. As a result of this, we should be able to deprecate `pulumi-java-gen` more safely when the time comes, remove direct build-time dependencies on `pulumi-java` from `pulumi/pulumi` and fix some issues that have arisen as a result of the historic differences, such as #1404 (which looks like it may have already been fixed, but this should cement it), and the Java side of #1508. Alongside new unit tests and existing conformance tests, this changeset has been manually tested using `pulumi-azure-native` and changes akin to those in pulumi/pulumi-azure-native#3776 (using a locally modified `pulumi package gen-sdk` that can be mainstreamed when these changes have been merged and released). Closes #1404 Part of #1508
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
Found while working on pulumi/pulumi-kubernetes#3151. pulumi-java-gen filled in default dependency versions that gen-sdk doesn't which required adding more dependencies explicitly in the schema.
Example
See pulumi/pulumi-kubernetes#3151
Output of
pulumi aboutJava 0.13.0
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: