Gradle plugin

Our plugin applies the Java plugin automatically. That doesn't make sense when you're building a pure Kotlin project and leads to unnecessary noise as the Java-related tasks are still run as part of the build:

$ ./gradlew classes
:compileKotlin
:compileJava UP-TO-DATE
:processResources
:classes

/cc @jkschneider

If looks like @Value might already support #{...} expressions as an alternative to ${...}.

Spring MVC

Reified extension functions for the RestOperations interface. There are probably similar better-typing gains to be made elsewhere.

Spring HATEOAS

Extension functions to improve the transformation of objects and collections of objects into Resource and PagedResources, respectively. Also better link generation for Resource and PagedResources.

Thanks for creating this issue @philwebb 👍, I am especially interested by removing the need for the open qualifier.

Maybe we could discuss Monday with the team if they would be ok to automatically register Kotlin Jackson module in Jackson2ObjectMapperBuilder if it is in the classpath like we do for various other modules (I could add this to Spring Framework 4.3 easily).

@jkschneider Good idea about Spring HATEOAS. Be aware that I also plan to experiment on allowing to specify relations thanks to annotations + regular data classes, see spring-projects/spring-hateoas#401 for more details. Nothing specific to Kotlin, but that will make it easier to deal with data classes in both Kotlin and Java.

@philwebb SPR-14108 + related pull request for Jackson Kotlin module automatic registration submitted for inclusion in Spring Framework 4.3.

I have just merged Jackson Kotlin module automatic registration, so it will be available in 4.3.0.RC1 upcoming release tomorrow and then in Spring Boot 1.4.

About @Value I did a quick test some times ago, and I dont remember # was supported out of the box as a dropin replacement for $, I think only @Value("#{config['foo']}) and @Value("\${foo}") were. That's why I described in this StackOverflow answer how to customize ${...} to something else. Is there a better solution available out of the box?

About extensions, Kotlin Primavera contains some examples of Kotlin extensions applied to Spring (I am sure there a lot of others to imagine even more useful).

I have tried to reproduce the "Default constructor arguments with @Autowired" described above in this test project but did not succeed. Any chance someone send a PR on this test project to show how to reproduce this issue?

You can find bellow some issues from Kotlin bugtracker related to Spring:

• Parent issue for Spring Framework support
• Allow specifying array annotation attribute single value without arrayOf() (target : 1.1)
• Add quick fix for "Spring @Configuration/@Component annotated classes or @Bean annotated methods should be open" (fixed in 1.0.2)
• Create intention for wrapping vararg annotation parameter with arrayOf() (fixed in 1.0.2)
• Callable reference with expression on the left hand side
• Infer type parameter to upper bound when no bounds can be inferred from arguments
• Spring: package name(s) in AnnotationConfigApplicationContext() call are not resolved
• Member vs SAM conversion with more specific signature (target : 1.1)

@lkogler - Hadi Hariri mentioned you as a Spek contributor. Thought you might be interested in this effort as well.

@sdeleuze Sent a PR for "Default constructor arguments with @Autowired". Adding required=false was a valid workaround as of some pre-1.0 release, but no longer works.

Thanks for putting together all of the links!

@philwebb or @sdeleuze if you could create a spring-kotlin project in spring-projects and give me commit access, I'll start pouring in the work I have here.

@jkschneider As a first step I have created the spring-kotlin in my own sdeleuze account. Maybe we could both of us (and any interested people) contribute anything useful for building Spring + Kotlin applications, including documentation. When the project will be mature enough, we will evaluate moving it to https://github.com/spring-projects.

I already gave you the push rights, please sign the CLA as explained in the README. I will setup the build process using http://build.spring.io and publish the snapshots in https://repo.spring.io/snapshot/ as soon as we have the first bits committed.

Does it sound ok for you?

@sdeleuze He's signed the CLA for spring cloud previously.

@sdeleuze thanks, sounds like a plan!

I'm interested as well, and have just signed (again?) the CLA - just to be sure.