java: Maven plugin and archetype for the CDK

[eladb]

@arun-gupta proposed that we will write a maven plugin for the CDK that will make the CDK java experience more idiomatic:

• [ ] Maven archetype for cdk projects instead of cdk init -l java
• [ ] Maven goals for the various cdk operations such as synthesis, deploy, diff
• [ ] Remove the need for cdk.json, app.sh, etc.
• [ ] Don't require to install node and the toolkit (we can do that by bundling the toolkit via the likes of pkg and then bundle into the Maven plugin for all architectures

[eladb]

@arun-gupta wrote:

• “cdk init app –language=java” is an atypical usage for Java programmers. This should be replaced with a Maven archetype otherwise everybody to create an empty directory first and then give this command. At least, “cdk init app --language=java” should create the directory. But I’d strongly recommend to provide a maven archetype that would generate the project structure and populate pom.xml accordingly.
• Using cdk.json to invoke app.sh which then relies upon classpath.txt which is generated by mvn package feels very contorted and very atypical usage in a maven project. This should be served by a maven plugin that should hide all those details. A user experience that would be much liked where they can invoke “mvn cdk:execute”, that plugin would do all the classpath wrangling and run the app.
• Commands like “cdk hello synth-sdk”, “cdk deploy”, “cdk diff” should be included in the proposed maven plugin. This would allow me to tie phases/goals and provide a seamless maven workflow.
• .classpath.txt is definitely not what is expected from a Java application built using Maven. As mentioned earlier, all these details should clearly be hiding inside a maven plugin.
• Expecting a Java developer to have npm tool is not normal. I feel more strongly that having a Maven plugin perform all the CDK operations would be the right abstraction. CDK CLI can also provide that functionality but that should not be needed for a Java developer.
• Generated app.sh does not have executable permission. Had to explicitly chmod +x it.

[eladb]

@kiiadi wrote:

when we do this we need to do so with the possibility of multiple build-tool implementations in mind. There are two popular build-tools in the Java community:

• maven – this is the classic system and probably has the most customers
• gradle – more modern, declarative style syntax with a dynamic task-graph. Gradle is gaining popularity – for example Google nominated it as the build-tool of choice for Android applications; it’s also recommended by JetBrains for use with Kotlin projects. For Scala customers working in the JVM ecosystem “sbt” is the defacto standard build-tool.

In an ideal world we’d support all 3 but for now I think it’s sufficient to create an abstract common library with ‘maven’ and ‘gradle’ bindings. The build-tool specific logic should be kept pretty minimal as we’ll want consistency across both tools.

[arun-gupta]

@eladb Gradle is pretty cool but Maven would capture significant part of the developer community IMHO. So for prioritization, start with Maven. If the code is modular then Gradle plugin would be just another wapper on top of the base code.

[thesurlydev]

+1 for Gradle as well as Kotlin for language. For orgs that are standardized on Gradle this is an impediment. Even better would be support for Gradle Kotlin DSL. I could see cli args being something like:

cdk init --language=java --build-tool=gradle dsl=kotlin

[thesurlydev]

I created #1293 to propose adding a Gradle plugin as well

[kavukcutolga]

Hi All,

Do you know of any initiative around a maven plugin for cdk commands? As you indicated at the beginning, having npm installed in java developer's machine or Jenkins machines is not a common approach. So we need a maven plugin to generate cloud formation template during build and we will publish generated template to s3 in our pipeline.

I know there is an option to do it via cdk command but we already have an existing codedeploy pipeline /flow triggered by s3 event. So we want to keep the same flow

[RoKish]

Hi guys,

I've created a aws-cdk-maven-plugin which solves some the issues described above. It eliminates the need of having Node.js and CDK toolkit installed on the machine. Please take a look and feel free to contribute.

[eladb]

Hi guys,

I've created a aws-cdk-maven-plugin which solves some the issues described above. It eliminates the need of having Node.js and CDK toolkit installed on the machine. Please take a look and feel free to contribute.

Looks great! Let’s add this to https://github.com/eladb/awesome-cdk

Wondering if we should also change our java unit template to use this

[RoKish]

@eladb Thanks!

I wouldn't update the java init template to use the plugin as it's not that stable. Besides it, you guys make a lot of changes in CDK and if the changes are related to CDK CLI, the plugin needs to be updated as well.

It could be added as an additional init template (i.e. app-maven-plugin), but in that case, the template will make sense only with --language=java.

[eladb]

I love the idea of an additional template. Would you be interested in submitting a PR for that?

[RoKish]

Sure, I'll create a PR.