-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
java: Unable to synth Java CDK projects #26604
Comments
same issue here |
Seems related to the release of AWS JSII 1.86 as it looks a lot like this issue : aws/jsii#4202. Wouldn't it possible to enforce a JSII version to each AWS CDK version to avoid any issues when we enforce the CDK versions on our sides? |
The registration was done on the object's prototype, and tthe value from the constructor was always used, even if that was inherited, such that if a parent type ahd already been resolved previously, all child types would use the parent's FQN instead of their own. Addressed this by instead storing the associations in an external WeakMap, and added a test case to validate correct behavior. Fixes aws/aws-cdk#26604
The registration was done on the object's prototype, and tthe value from the constructor was always used, even if that was inherited, such that if a parent type ahd already been resolved previously, all child types would use the parent's FQN instead of their own. Addressed this by instead storing the associations in an external WeakMap, and added a test case to validate correct behavior. Fixes aws/aws-cdk#26604
If that was done, you suddenly would be required to ensure ALL packages in your dependency closure were built by the EXACT SAME version of |
As a workaround until I get around to publish a fix, you should be able to pin the version of |
I fixed it by adding the explicit jsii-runtime version of your dependency. For example, in my project I had:
When checking which jsii-runtime version is included (see compile dependency): https://mvnrepository.com/artifact/software.amazon.awscdk/aws-cdk-lib/2.83.1 Exclude the jsii-runtime, and add the jsii-runtime explicitly in your pom file:
|
The registration was done on the object's prototype, and the value from the constructor was always used, even if that was inherited, such that if a parent type had already been resolved previously, all child types would use the parent's FQN instead of their own. Addressed this by instead storing the associations in an external WeakMap, and added a test case to validate correct behavior. Fixes aws/aws-cdk#26604 Fixes #4202 Fixes #4203
|
The registration was done on the object's prototype, and tthe value from the constructor was always used, even if that was inherited, such that if a parent type ahd already been resolved previously, all child types would use the parent's FQN instead of their own. Addressed this by instead storing the associations in an external WeakMap, and added a test case to validate correct behavior. Fixes aws/aws-cdk#26604
@RomainMuller I wonder why you guys are not using fixed versions for all dependencies in CDK. This issue broke our prod release which deployed just fine on the upstream environments a couple of hours earlier. That's not nice. |
@RomainMuller But currently the jsii-runtime version already changes as AWS publishes new versions of it. So how fixing the version would cause problems with the jsii pacmak as changing versions would not? Gradle or Maven will be able to see different versions of jsii required by all modules but would then use the best one automatically so one version is used across a project. |
Describe the bug
We are unable to synth and deploy CDK projects written in Java since today.
Yesterday, the same projects with the same commit were building correctly.
Expected Behavior
Our CDK project synths properly.
Current Behavior
It throws errors like that (the resource class name vary depending on the project and which resource comes first) :
Reproduction Steps
Any Java project on our stack seems impacted, I think the standard CDK example should have the same issue.
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.89 (but various 2.x versions of the CDK lib used)
Framework Version
Java 11/17
Node.js Version
16.20.1
OS
Mac OS X (M1)
Language
Java
Language Version
11/17
Other information
No response
The text was updated successfully, but these errors were encountered: