Java init template #229
Java init template #229
Conversation
Include the pom.xml file in the maven repo, so that transitive dependencies will be respected. This also required us to clean up the file and not include the path to the jsii-runtime repo. Instead, we simply deploy it into ~/.m2 during `./generate.sh`. Not ideal, but works for now. When jsii is published to Maven Central, this is all going to go away, so trying to not over-engineer it.
The template includes a java shim for the toolkit called "app.sh". The shim depends on a file `.classpath.txt` that's generated by maven during build. It points to `target/classes` for classpath. This supports a workflow where you can iterate in the IDE (and run unit tests), but then go to the command line to execute the toolkit, and you will target the same classes the IDE compiled. BETA: the template includes a pom.xml file that depends on `~/.cdk/repo/maven` as a pragmatic solution for beta. There's value in adding the repository in the pom.xml file directly as this gets us seamless IDE experience that works out of the box.
packages/aws-cdk-java/generate.sh
Outdated
| @@ -3,6 +3,11 @@ set -euo pipefail | |||
|
|
|||
| mkdir -p project | |||
|
|
|||
| # deploy jsii-runtime to the local maven repo so it will be discoverable | |||
| jsii_runtime_repo=$(node -e "console.log(path.join(path.dirname(require.resolve('jsii-java-runtime')), 'maven-repo'))") | |||
There was a problem hiding this comment.
This path will be that of whatever file the main field of package.json points to, which can be considered an implementation detail. I would advise against depending on that. Using the path to require.resolve('jsii-java-runtime/package.json') would be better. And better yet would be making jsii-java-runtime have an actual JS function or property that provides the path to the repository root.
There was a problem hiding this comment.
Nice catch. Changed to require.resolve('jsii-java-runtime/package.json')
packages/aws-cdk-java/generate.sh
Outdated
| @@ -3,6 +3,11 @@ set -euo pipefail | |||
|
|
|||
| mkdir -p project | |||
|
|
|||
| # deploy jsii-runtime to the local maven repo so it will be discoverable | |||
| jsii_runtime_repo=$(node -e "console.log(path.join(path.dirname(require.resolve('jsii-java-runtime')), 'maven-repo'))") | |||
| mkdir -p ~/.m2/repository | |||
There was a problem hiding this comment.
I do not like how you're going to be messing with my ~/.m2 as part of this. There could be things in there that will interfere with the build, and this could cause the build to interfere with some of my things.
There was a problem hiding this comment.
As mentioned in the commit message, this is going away very soon once we publish jsii to Maven Central. For now, this seems like a pragmatic option.
| @@ -0,0 +1,3 @@ | |||
| { | |||
| "app": "./app.sh" | |||
There was a problem hiding this comment.
I doubt this is windows-friendly.
There was a problem hiding this comment.
😢 you are probably correct. I'll add to #138
|
|
||
| public class HelloStackTest { | ||
| private static ObjectMapper JSON = new ObjectMapper() | ||
| .configure(SerializationFeature.INDENT_OUTPUT, true); |
There was a problem hiding this comment.
I don't like this way to indent the chain... Would prefer (but no hard feelings):
private static ObjectMapper JSON =
new ObjectMapper().configure(SerializationFeature.INDENT_OUTPUT, true);Also, should be private final static
The template includes a java shim for the toolkit called "app.sh". The shim depends on a file
.classpath.txtthat's generated by maven during build. It points totarget/classesfor classpath. This supports a workflow where you can iterate in the IDE (and run unit tests), but then go to the command line to execute the toolkit, and you will target the same classes the IDE compiled.BETA: the template includes a pom.xml file that depends on
~/.cdk/repo/mavenas a pragmatic solution for beta. There's value in adding the repository in the pom.xml file directly as this gets us seamless IDE experience that works out of the box.