Create Kotlin extension #1059

geoand · 2019-02-26T17:58:39Z

The basic functionality of changing a Kotlin source file and having the quarkus:dev recompile seems to work fine.

There are of course a few things I don't really like:

~~In order for the devmode to work with Kotlin, the user needs to add~~

    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-compiler-embeddable</artifactId>
      <version>${kotlin.version}</version>
      <optional>true</optional>
    </dependency>

This is somewhat analogous with what users have to do with spring-boot-devtools.
I am guessing we could alternatively download the that artifact and make it available on the user's classpath when we detect that we are working on a Kotlin app?

Although the diagnostics work, they could obviously use some polish in how they are displayed
~~The implementation could use a lot more polish to abstract away which compiler is to be used. I just went for the fastest thing I could do to get up to speed.~~

UPDATE

See: #1059 (comment) for the latest on what the PR provides

metacosm · 2019-02-26T20:38:07Z

devtools/maven/src/test/java/io/quarkus/maven/it/DevMojoIT.java

+        sleep();
+        filter(source, ImmutableMap.of(uuid, "carambar"));
+
+        // Wait until we get "uuid"


This should be "carambar", not "uuid" :)

True, I just copied it from one the existing tests. I'll fix them

stuartwdouglas · 2019-02-27T02:29:53Z

Nice!

I think we probably want some kind of quarkus-kotlin extension, and include all the Kotlin related stuff in it, which at this stage would require adding some more SPI's to the developer tools. On the flip side it would also be really good to have some Kotlin support at release time, so I am not sure if we should hold off or not.

geoand · 2019-02-27T05:43:03Z

@stuartwdouglas If you have an SPI in mind, then I'd gladly refactor the PR to use it (while also moving it into a new module).
On the other hand this works now and we can obviously improve later 😎.

Whatever you think is appropriate, I'll gladly roll with!

mkouba · 2019-02-27T06:45:45Z

core/devmode/src/main/java/io/quarkus/dev/RuntimeUpdatesProcessor.java

                        .filter(p -> wasRecentlyModified(p))
                        .map(Path::toFile)
                        //Needing a concurrent Set, not many standard options:
-                        .collect(Collectors.toCollection(ConcurrentSkipListSet::new));
+                        .collect(Collectors.toSet());


I think we still need a concurrent set, or? Collectors.toSet() is using HashSet...

This is only used to test and log stuff. The actual collection that the compiler uses is created a few lines down

Well, you still need some sort of synchronization because it's a parallel stream. And vice versa - you probably don't need the ConcurrentSkipListSet below...

A damn... You are absolutely right! I didn't see the parallel stream...
Thanks for spotting it! I'll fix it ASAP

mkouba · 2019-02-27T07:08:08Z

I think it would be smart to have a kotlin guide for the first public release. I did try to use kotlin with quarkus last week and faollowed the kotlin guide and it just worked (basics of course). The only missing piece was the dev mode. So I'd merge this PR and create the guide and possibly create some extension/improve later?

geoand · 2019-02-27T07:14:17Z

If we get this in, then I will also create a guide for it.

Then once quarkus is released I can proceed to create an kotlin compiler plugin to automatically "open" classes with certain annotations (just like the kotlin-spring plugin).
That way we could make things even easier for the users

Ladicek · 2019-02-27T09:40:48Z

Did you try a "mixed change"? I mean, reloading after a change both in a Java source and Kotlin source, where one depends on the other. My understanding is that mixed projects are relatively common in the Kotlin world.

geoand · 2019-02-27T09:42:47Z

Did you try a "mixed change"? I mean, reloading after a change both in a Java source and Kotlin source, where one depends on the other. My understanding is that mixed projects are relatively common in the Kotlin world.

I have not and my guess is that it probably won't work, but I am fairly certain that we could get it to (I vaguely remember seeing some flags about compiling Java).
My idea is that Kotlin reloading could be something of a "preview" at the first release and only meant to be used on Kotlin-only modules.

geoand · 2019-02-27T18:43:02Z

Nice!

I think we probably want some kind of quarkus-kotlin extension, and include all the Kotlin related stuff in it, which at this stage would require adding some more SPI's to the developer tools. On the flip side it would also be really good to have some Kotlin support at release time, so I am not sure if we should hold off or not.

If we had a quarkus-kotlin then it would make sense to also generate Kotlin source files from the create goal of the Maven plugin. If we don't do that, then I believe that having the extension will confuse users.
If we do have the extension then we could move everything there, provide a proper guide and have an all-around Kotlin experience.

I suggest that we merge this (if it's up to the project standards that is) and then follow up with a full blown Kotlin extension with a first version of the compiler SPI if time permits.

geoand · 2019-03-01T06:27:38Z

Did you try a "mixed change"? I mean, reloading after a change both in a Java source and Kotlin source, where one depends on the other. My understanding is that mixed projects are relatively common in the Kotlin world.

According to this it's possible, but I'm not sure it's something we want to try to support

geoand · 2019-03-01T07:09:38Z

I (seemingly) have some extra cycles so I will look into breaking this work out into a Kotlin extension.
The plan is to introduce a rudimentary SPI for the compilation and also update the cli to generate Kotlin code when the Kotlin extension is selected.

gsmet · 2019-03-01T09:03:12Z

@geoand btw, we will need some sort of quickstart for this feature as we need to shed some light on it.

geoand · 2019-03-01T09:04:13Z

@gsmet Yes of course. I'm working on breaking things out into an extension now. Once that is done, I will also add a quick-start and a guide

Ladicek · 2019-03-01T10:03:51Z

Did you try a "mixed change"? I mean, reloading after a change both in a Java source and Kotlin source, where one depends on the other. My understanding is that mixed projects are relatively common in the Kotlin world.

According to this it's possible, but I'm not sure it's something we want to try to support

I know it's possible, as it's a big part of their gradual Java -> Kotlin migration story. I think you already invoke the Kotlin compiler before the Java compiler, so it should be just a matter of passing some arguments to it, I think? :-)

geoand · 2019-03-01T10:06:34Z

Did you try a "mixed change"? I mean, reloading after a change both in a Java source and Kotlin source, where one depends on the other. My understanding is that mixed projects are relatively common in the Kotlin world.

According to this it's possible, but I'm not sure it's something we want to try to support

I know it's possible, as it's a big part of their gradual Java -> Kotlin migration story. I think you already invoke the Kotlin compiler before the Java compiler, so it should be just a matter of passing some arguments to it, I think? :-)

I don't really to know to be honest :). Having everything work OOTB for mixed projects would be awesome, but I don't think I have enough time to get it done properly at the moment.
I believe that for the first release having a Kotlin extension that simply gives users a Kotlin-only project setup should be the first step. Then we can obviously improve a lot of things :)

geoand · 2019-03-01T12:15:10Z

The PR now introduces the ability to generate a properly configured Maven+Kotlin project when the Maven create goal is invoked and the user supplies the kotlin extension as part of the extensions list.

So I would say that it should be complete for the first release. Please give it a try and let me know what you think

geoand · 2019-03-01T14:26:21Z

I need to see why the tests are failing. I'll do that in a few hours

geoand · 2019-03-01T20:17:18Z

Tests should pass now

geoand · 2019-03-02T10:14:30Z

Rebased onto latest bom/build-parent changes

geoand · 2019-03-02T17:14:38Z

Are we planning to merge this before the first public release? Just asking because in that case I need to start writing a guide as well.

gsmet · 2019-03-02T17:42:44Z

@geoand could you squash things a bit?

I think it's something we would want but I can't assure you we will have the cycles to review it.

Can you start working on the guide anyway? That won't be time wasted as we will integrate this at some point.

Adds support for a hot reload in Kotlin and also gives the ability to create Kotlin source code from the Maven plugin

geoand · 2019-03-02T17:51:09Z

@gsmet I squashed to a single commit.

I'll start writing on Monday and if we want to merge this then I'll get it done ASAP

metacosm reviewed Feb 26, 2019

View reviewed changes

mkouba reviewed Feb 27, 2019

View reviewed changes

geoand force-pushed the kotlin-devmode branch 2 times, most recently from a690087 to 0fbfeeb Compare March 1, 2019 08:40

geoand changed the title ~~Add first very rough version of dev mode for Kotlin~~ Add first version of dev mode for Kotlin Mar 1, 2019

geoand force-pushed the kotlin-devmode branch from 227b375 to 556d6ff Compare March 1, 2019 12:14

geoand force-pushed the kotlin-devmode branch from 556d6ff to 6956e38 Compare March 1, 2019 16:20

geoand changed the title ~~Add first version of dev mode for Kotlin~~ Add Kotlin extension Mar 1, 2019

geoand changed the title ~~Add Kotlin extension~~ Create Kotlin extension Mar 1, 2019

geoand force-pushed the kotlin-devmode branch from 7159227 to b2118d0 Compare March 1, 2019 19:16

geoand force-pushed the kotlin-devmode branch from a73894f to 029b5e6 Compare March 2, 2019 10:01

Create Kotlin extension

7f43831

Adds support for a hot reload in Kotlin and also gives the ability to create Kotlin source code from the Maven plugin

geoand force-pushed the kotlin-devmode branch from 029b5e6 to 7f43831 Compare March 2, 2019 17:50

Merge branch 'master' into kotlin-devmode

9f04da6

starksm64 approved these changes Mar 3, 2019

View reviewed changes

starksm64 merged commit 96a1ae9 into quarkusio:master Mar 3, 2019

geoand deleted the kotlin-devmode branch March 3, 2019 02:00

gsmet added this to the 0.11.0 milestone Mar 3, 2019

emmanuelbernard added release/noteworthy-feature and removed coding-in-progress labels Mar 5, 2019

gsmet mentioned this pull request Mar 12, 2019

Scala language support #1413

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create Kotlin extension #1059

Create Kotlin extension #1059

geoand commented Feb 26, 2019 •

edited

Loading

metacosm Feb 26, 2019

geoand Feb 26, 2019

geoand Feb 27, 2019

stuartwdouglas commented Feb 27, 2019

geoand commented Feb 27, 2019

mkouba Feb 27, 2019

geoand Feb 27, 2019

mkouba Feb 27, 2019

geoand Feb 27, 2019

geoand Feb 27, 2019

mkouba commented Feb 27, 2019

geoand commented Feb 27, 2019 •

edited

Loading

Ladicek commented Feb 27, 2019

geoand commented Feb 27, 2019 •

edited

Loading

geoand commented Feb 27, 2019 •

edited

Loading

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019

gsmet commented Mar 1, 2019

geoand commented Mar 1, 2019

Ladicek commented Mar 1, 2019

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019 •

edited

Loading

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019

geoand commented Mar 2, 2019

geoand commented Mar 2, 2019

gsmet commented Mar 2, 2019

geoand commented Mar 2, 2019 •

edited

Loading

Create Kotlin extension #1059

Create Kotlin extension #1059

Conversation

geoand commented Feb 26, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stuartwdouglas commented Feb 27, 2019

geoand commented Feb 27, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkouba commented Feb 27, 2019

geoand commented Feb 27, 2019 • edited Loading

Ladicek commented Feb 27, 2019

geoand commented Feb 27, 2019 • edited Loading

geoand commented Feb 27, 2019 • edited Loading

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019

gsmet commented Mar 1, 2019

geoand commented Mar 1, 2019

Ladicek commented Mar 1, 2019

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019 • edited Loading

geoand commented Mar 1, 2019

geoand commented Mar 1, 2019

geoand commented Mar 2, 2019

geoand commented Mar 2, 2019

gsmet commented Mar 2, 2019

geoand commented Mar 2, 2019 • edited Loading

geoand commented Feb 26, 2019 •

edited

Loading

geoand commented Feb 27, 2019 •

edited

Loading

geoand commented Feb 27, 2019 •

edited

Loading

geoand commented Feb 27, 2019 •

edited

Loading

geoand commented Mar 1, 2019 •

edited

Loading

geoand commented Mar 2, 2019 •

edited

Loading