I have found the reason this bug happens. Documented in the issue. In short: for some reason when using 'directory = customdir' class files are still being put to

kobaltBuild

at the root directory, rather than to

customdir/kobaltBuild

. So they are never found by an

assemble

task and don't get put to the resulting jar...

Oh nice job. Silly bug

So it’s a bug in the application plug-in

was wondering why I hadn’t come across that earlier, guess I never tried to run a project in a sub dir

I'm not sure I could do a PR (would take me long I guess) and I have not very much time after work to try this 🙂 But maybe I'll still manage to do it (if someone wouldn't do it faster)

Come to think of it,

kobalt

itself is a project I call

run

on all the time, but it’s in

rootDir

Hm. But I invoke

run

from the root dir too

I also not sure why it didn't surface earlier. I see some projects with multi-project Build.kt and they have the same setup. I assume they work somehow 🙂

Like

ktor

for example

But maybe they never invoke

run

But still, the result of this bug, is that resulting

jar

doesn't contain subproject classes at all

I still suspect this might somehow be result of my setup. Well, either I'll try to debug it even more with kobalt built from sources or someone will reproduce it 🙂

Also maybe those projects do not use application plugin

I’ll take a look too as soon as I get a chance, I’ll update the issue if I do so we don’t duplicate work

Yes that’s what I mean with my

run

comment: that bug only happens for .1) projects with

application{}

and 2) projects that are not on

rootDir

. Probably a very tiny set.

OK, thanks. it's great that you're active, Kobalt seems like such a nice and simple tool

Glad you like it!

I split my time between klaxon and kobalt, wherever I’m needed.

I saw Klaxon too and it's on my 'curious to pick-and-try' list too 🙂

But I have concrete plans for Kobalt - as I've just had an idea for small utility library and I plan to use it.

Don’t hesitate to ask here if you get stuck

yes, thank you

Looks suspicious: https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/plugin/application/ApplicationPlugin.kt#L123

I also not sure that it is solely an application's plugin fault. I figured that

kotlinc

gets run by

KotlinCompiler.kt

and that's where that

-d

option with wrong output dir for classes gets applied.

Can’t comment until I’ve dug into this. These flags are being set by plug-ins, which contribute what they need to the command line

Also @dimsuz, just saw your question on #general: for Kobalt, it’s

./kobaltw --noIncrementalKotlin

to disable incremental compilation

oh. right. then this still may be the plugin 🙂 Ok, this requires digging in indeed...

yeah, simple one in kobalt!

Remember the way Kobalt works with its plug-in architecture is that when it’s trying to create a command line to run the compiler, it asks all the plug-ins that implement

ICompilerFlagContributor

“give me your flags”, “give me your flags”, etc…

Going to look at the closed bugs, sounds very familiar.