| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Would it not make more sense to name them commandapi-kotlin-core, commandapi-kotlin-bukkit and commandapi-kotlin-velocity? |
Sorry, something went wrong.
Yes, I thought about this too. I thought if this is for 9.2.0 it might make more sense to leave the module names as they are because with this change a dependency change from commandapi-bukkit-kotlin to commandapi-kotlin-bukkit would be necessary and I am not sure that this is something we want for a minor version. |
Sorry, something went wrong.
Makes sense to me 👍 |
Sorry, something went wrong.
There was a problem hiding this comment.
Just some notes about the pom.xml files.
I don't know enough to judge the Kotlin part, but it probably works. Maybe there could be some tests added for the feature.
Sorry, something went wrong.
@willkroboth Thanks about the project version thingy though, I totally forgot that! About the structure and the file paths. Given that it works I don't think the profile thing should be added to commandapi-kotlin. The goal of this was to have all the Kotlin stuff organized (hence the removal of commandapi-[platform]-kotlin from the commandapi-[platform] module) and I wanted no code repetition if possible which is why I added commandapi-kotlin in the first place. I am also planning on doing some more testing with the modules to see how they behave when set up differently but that's nothing that I want to get too deep into now. |
Sorry, something went wrong.
There was a problem hiding this comment.
Just one comment on the tests.
I still think it makes sense to put
<modules>
<module>commandapi-core-kotlin</module>
</modules>
<profiles>
<profile>
<id>Platform.Bukkit</id>
<modules>
<module>commandapi-bukkit-kotlin</module>
</modules>
</profile>
<profile>
<id>Platform.Velocity</id>
<modules>
<module>commandapi-velocity-kotlin</module>
</modules>
</profile>
</profiles>into the pom.xml of commandapi-kotlin. If you want all the Kotlin stuff in the same place, that would keep all the Kotlin stuff inside the kotlin module instead of putting it in commandapi-platforms.
If you want it to be more clear what belongs to Bukkit/Velocity, you should put commandapi-bukkit-kotlin inside commandapi-bukkit's pom and commandapi-velocity-kotlin inside commandapi-velocity's pom, like it was before this PR. You do have to do the path traversal, which I think makes this slightly worse, but the purpose of the commandapi-[platform] modules are to store the platform-specific modules.
However, I suppose building the CommandAPI is functionally the same in any of these ways, so I'm not requesting changes for that anymore.
Sorry, something went wrong.
There was a problem hiding this comment.
Looks good to me, to the extent that I can judge Kotlin code :P. I like the extra check that the exception message is right.
Still not sure about this: https://github.com/JorelAli/CommandAPI/pull/482/files#r1297831688, but oh well.
I'm guessing docs are on the TODO list? Oh wait, just noticed the PR description has a TODO list now, lol
Sorry, something went wrong.
…Kotlin's documentation for delegated properties
| Back | FazBrowse Home | New Git URL |
As suggested by Sparky in the CommandAPI Discord, this PR is adding support for delegations in the Kotlin DSL.
This would allow retrieving arguments like this:
Or, in the Kotlin DSL:
This PR restructures the Kotlin DSL modules which are now no longer included in the commandapi-bukkit and commandapi-velocity modules. Instead, the commandapi-kotlin module has been added to the root of the project which contains three modules: commandapi-core-kotlin, commandapi-bukkit-kotlin and commandapi-velocity-kotlin.
This results in this structure:
To still be able to build all modules that belong to a specific platform, these modules have also been added to the commandapi-platforms pom.xml.
ToDo's: