Setup JavaRosa for Kotlin development #724
Comments
|
So that we're on the same page, this is about building a mixed java-kotlin source code into a package for deployment on the jvm. The success criteria is building artefact that can be deployed on a jvm platform of the eq spec of today. Out of scope is spending much effort to get the converted code to be "good" Kotlin rather than java converted to Kotlin. |
|
Forgot to add "needs discussion" so just added it now.
Yeah that feels correct. I can write acceptance criteria (we often use a given-when-then/gherkin style) if that's helpful for us to make sure this is clear? |
|
Only if you want to. I think it's clear enough. And will be reviewed regardless. |
|
Great! I'll assign this to you then. |
|
Does anyone have strong opinions about whether kotlin files should be under Personally, I don't think it matters, and prolly less faff to leave them under @lognaturel @seadowg - thoughts? |
|
While I'm here - are you happy fo rme to update the maven-compiler-plugin from 3.8 to 3.11? Similar question for gradle from 3.6 to 3.8? |
Great question! I've never separated them out before and we use
I'm assuming that's required for the latest Kotlin versions. I'm not aware of any blockers to doing that off the top of my head! |
New code in Collect has been written in Kotlin by default for a few years now (following this PR), and we've wanted to be able to write Kotlin in JavaRosa also.
It's important to note that adding Kotlin to JavaRosa means setting Kotlin up for Gradle and Maven as JavaRosa currently uses both. The former is for day to day to development and the latter is used to publish JavaRosa. It's likely that it's possible to publish using Gradle, so it could be that moving to this approach is easier than getting Kotlin working for Maven (and either is acceptable).
Existing code and test will need to converted to Kotlin to demonstrate that the tooling is working correctly. I think converting everything in
entitieswould be a good candidate as this code is not being touched a lot at the moment, is fairly isolated from the rest of the code base (we've even considered making it its own module) and makes use of things like Java Streams that would benefit from conversion to Kotlin (EntityFormFinalizationProcessorfor example).The text was updated successfully, but these errors were encountered: