ah ok. will it allow the execution of functions at the top level?

i mean, execution of arbitrary code

yes

Will clean up the syntax of kobalt build files somewhat

cedric: btw kotlinw throws an exception if no arguments are provided simple smile

yeah it’s a newline problem in the kobaltw script, fixed in the repo

The joy of switching between Windows and Mac OS all the time (kind of important for kobalt though)

is kobalt using the Gradle API? the

Build.kt

in the repos looks very nice.

No, zero dependency on groovy nor gradle

Glad you like the format!

hi @eddie I see you got your nick here 😉

yes indeed simple smile

Welcome to #C0BRKJ9K9 to discuss it! 😉

I’m particularly happy about JCommander’s build file: https://github.com/cbeust/jcommander/blob/master/Build.kt

Also, for random chats we always have our best cafe right around the corner in #C09222272 simple smile

my problem with Gradle is, that it does a lot of magic and it is hard to have perfect IDE support. to have a build system that uses Kotlin's static typed builders would be better.

is this a polite way of saying we’re offtopic ilya? simple smile

I’m just saying there is much more comfortable to discuss these topics — not interleaved with some #C0922A726 questions 😉

@hastebrot: That’s exactly what led me to write Kobalt, tired of spending hours on Stack Overflow to guess gradle’s magic keywords and syntax. Hopefully I can do a bit better with Kobalt

ah i see, this is a Q&A channel. i did not realise

I’d say it is more of a routing channel. But quick Q&A is fine, sure. I’m afraid with 360 ppl onboard we can easy overflow anyone’s screen capacity, if we talk everything in a single channel.

@cedric: to write tests for existing Gradle plugins, that tests

Extension

,

Plugin

and such was a little nightmare, because they use a lot of dynamic code for them. However, I haven't checked the new test API for Gradle out. Anyway the problem was the dynamic stuff in the plugins main code.

looks definately very promising

@hastebrot: Agreed. I actually have already tested that Kotlin’s extension methods allow you to plug into existing elements, so you get the full flexibility that Groovy offers with Gradle, except much more statically typed

I have an example plug-in that adds elements to

Project

with extension methods, it’s very neat

extension methods for

Project

? for a functionality similar to Gradle's

project.ext { ... }

?

@hastebrot: Even better, adding whole methods. For example, right now,

Project

contains

sourceDirectories

and

sourceDirectoriesTest

. I wrote a coverage plug-in that also adds a section

sourceDirectoriesCoverage

.

how can I check why *.class is not generated?

I have *.kt class but for some reason, when I’m running tests from

./gradle clean testDebug

first time class is missing. If i run without

clean

again - all is good.