KoDEx convention plugin

[Jolanrensen]

created dfbuild.kodex convention plugin, migrated :core and csv to use it

Helps #1661 and to a lesser extent #985,

[koperagen]

Why is this needed here but not in csv module? What part of previous code corresponds to this logic?

[Jolanrensen]

since the convention plugin loads first, it doesn't pick up the additions of "generated-dataschema-accessors" to the kotlin main/test source sets. This is a problem, because it would mean they didn't end up in the final jars... (and csv does not have such an additional sourceset)

Maybe I could simplify the logic somewhat: Instead of "extra" sources, you're simply allowed to override the sourcesets used by KoDEx :) that would be similar to the extension notation of KoDEx we don't use yet (because I didn't get around to finishing it yet):

kodex {
    preprocess(mySourceSet) { ... }
}

[Jolanrensen]

actually... maybe I can already use the kodex {} extension notation. It's just the jar creation that needs more work figuring out, but we can leave that as is

[Jolanrensen]

on second thought... this may need some consideration, as there are some sourcesets that do need to be handled by KoDEx but don't need to be in the final jar (like src/test) and the kodex {} notation doesn't support that kind of setup yet... Still, this convention plugin could be a good trial run for a design of that :)

[Jolanrensen]

ah, it seems asking the sourcesets in afterEvaluate {} seems to get the most up-to-date version :D

[Jolanrensen]

Following up on #1765 (comment):

I found out we had quite a difficult setup with how we processed our code:

generated code --------------> jars
                             /
source code --> KoDEx --> linter
              /       \
tests -------           not in jars

Not only is this difficult to understand, but it's also hard to maintain.

I simplified it as follows:

(main) generated code
                    \
(main) source code --> KoDEx ---> linter --> jars      (main)
                     /      \
(contextual) tests -           not in jars             (contextual)

In the new setup, both the generated code and source code form the "main" sourceset, which is exactly how the module forms it, all is processed by KoDEx, the results are linted, and the jars are created from that.

Besides this, we have a "contextual" sourceset, which by default includes the tests. This makes it so we can refer to tests from the main sourceset from KoDEx and include samples with @sample. However, this sourceset will not be included in any jars.

I was able to gather the "complete" sourcesets by getting the directories inside afterEvaluate {}, which makes any module-specific code run first before these parts of the convention plugin, and it makes any specific setup obsolete :). I will keep the extension, though, as we may need it in the future.

...

Now trying to make it build successfully...