Conversation
…uild that can build the projects in /example/projects
…jects(/dev) to automatically be synced and built
2ec6075 to
a20f5a7
Compare
…oved kotlin-dataframe-plugin-maven-example to examples/projects and examples/projects/dev
…ilt when specifying android.sdk.dir
253d408 to
bc241e6
Compare
bc241e6 to
96714c6
Compare
461e286 to
31256ad
Compare
31256ad to
bd9bd74
Compare
…htly to allow more customization which tests should run from gradle
…can run them in parallel. reenabling buildExampleFolders in debug mode.
e9db608 to
296d0f2
Compare
…ze for android examples back to 2G
c6d4648 to
6bfabfd
Compare
6bfabfd to
b8b83db
Compare
0405eb2 to
42fe842
Compare
|
I might squash some commits later, as there's been a lot of trial-and-error between me and TeamCity, but all seems to build fine now :) Carefully read the documentation I wrote. It should explain most of the steps in detail. |
| // Apache Arrow is not supported well on Android. | ||
| // | ||
| // Either use: | ||
| implementation(libs.dataframe.core) |
There was a problem hiding this comment.
I still believe this notation makes lives of users harder. Impossible to copy paste dependency or even remember it
There was a problem hiding this comment.
Seems that it's needed for easier sync
There was a problem hiding this comment.
I think it's okay, since we will provide them an all-in-one project with libs.versions.toml. This is also the recommended structure by Gradle, so I guess we would just help them this way :)
And indeed, it makes sync way easier!
build-logic/README.md
Outdated
| - `sync<NameOfFolder(Dev)>`: Syncs and overwrites build settings and versions. | ||
| Copies and overwrites versions from the main `libs.versions.toml`, `gradle.properties`, etc. | ||
| - `syncAllExampleFolders`: Syncs all example projects. Automatically called on `assemble`. | ||
| - `promoteExamples`: Promotes the `/examples/projects/dev` example projects to `/examples/project`. |
There was a problem hiding this comment.
sure, sounds like a better name :)
| settingsGradleKts.writeText(newSettingsGradleKtsContent) | ||
|
|
||
| // overwrite .editorconfig | ||
| folder.resolve(".editorconfig").writeText(sourceEditorConfig.readText()) |
There was a problem hiding this comment.
Should we bundle editorconfig with our rules to examples projects?
There was a problem hiding this comment.
We don't necessarily have to, but we did tweak the settings to work well with DataFrame. Plus, if we bump KtLint, the version will be synced to the examples as well. If we then need to disable one of the new rules, we will need to do so in each example as well... So yeah
There was a problem hiding this comment.
Doesn't it work for us even without these files, re-using root editorconfig for entire dataframe project?
People like freedom to choose codestyle in their projects, i don't see why we should enforce anything beyond what IntelliJ already does
zaleslaw
left a comment
There was a problem hiding this comment.
Please answer my comments, also plan the task for the documentation update (and put it in the line of our site updates which should be merged closer to the release)
https://kotlin.github.io/dataframe/guides-and-examples.html#examples
Check references, paths, its description and possible notes for a user
|
|
||
| gradlePlugin-gradle-foojayToolchains = { module = "org.gradle.toolchains:foojay-resolver", version.ref = "gradlePlugin-gradle-foojayToolchains" } | ||
| typesafe-conventions = { module = "dev.panuszewski:typesafe-conventions-gradle-plugin", version.ref = "typesafe-conventions" } | ||
| maven-invoker = { module = "org.apache.maven.shared:maven-invoker", version.ref = "maven-invoker" } |
There was a problem hiding this comment.
well... maven XD
There was a problem hiding this comment.
It's added as dependency to the sourceSet running the build tests. Maven invoker can programmatically run a maven build, so we can even test our non-gradle examples :)
| The example projects in [examples/projects](projects) always target the latest stable version of the library. | ||
| Projects compatible with the latest dev/master version are located in the [examples/projects/dev](projects/dev) folder. | ||
|
|
||
| All examples are tested by the main project in debug mode when `gradlew test` is run |
There was a problem hiding this comment.
Also could be a useful information for our site https://kotlin.github.io/dataframe/guides-and-examples.html#examples
There was a problem hiding this comment.
I'm not sure. We could, but then it would be mostly boasting about how well we are looking after our examples. I think most users actually already expect we test our examples (I mean, we expected it ourselves too). What is more interesting for users is that they are kept up-to-date :) meaning they can always download a working, up-to-date example from the latest green-built master :)
| <repositories> | ||
| <repository> | ||
| <id>mavenLocal</id> | ||
| <url>file://${user.home}/.m2/repository</url> |
There was a problem hiding this comment.
Will it work on windows? hmmm
| @@ -0,0 +1,41 @@ | |||
| root = true | |||
There was a problem hiding this comment.
do we need this file in each project?
There was a problem hiding this comment.
yes, definitely. Each project should be individually downloadable as Zip. If you don't supply root=true, KtLint will scan the entire system upwards to find all .editorconfig files.
| # Specifies the JVM arguments used for the daemon process. | ||
| # The setting is particularly useful for tweaking memory settings. | ||
| org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8 | ||
| org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m -Dfile.encoding=UTF-8 |
There was a problem hiding this comment.
Does it require so much Metasspace?
There was a problem hiding this comment.
Not entirely sure, but what I am sure is that we need to limit this somehow, as to not exceed TeamCity's memory. This makes it so the test won't use more than 2.5GB
| * `dfbuild.buildExampleProjects` convention plugin. | ||
| */ | ||
| @Suppress("unused") | ||
| abstract class TestBuildingExampleProjects { |
There was a problem hiding this comment.
I have a feeling that we need to add this to our knowledge library: for example you should demo it for particular version and we will record it
| } | ||
|
|
||
| tasks.named<JavaCompile>("compile${testBuildingExamples.name.capitalized()}Java") { | ||
| sourceCompatibility = JavaVersion.VERSION_21.toString() |
There was a problem hiding this comment.
Should we somehow parametrize it to make easier migration on the next Java?
There was a problem hiding this comment.
Might be a good idea indeed :) this is the jvm version of :build-logic itself, but we can access our version catalog from there as well, so we might just be able to put it there :)
| typealias Code = String | ||
|
|
||
| @Language("kt") | ||
| fun generateTestCase(testClassName: String, folder: File, isDev: Boolean, tags: List<String>): Code = |
There was a problem hiding this comment.
I have a feeling that it should be a description of the processes, its goal, why do we need this generation
@koperagen Exactly :) see |


Fixes #1614
Step 3 of #1661
Introduces example structure like:
Dev versions of the examples are built using the sources of the project, while release examples use the latest release versions.
Since any example is a completely separate project, you can attach them to the IDE separately only if you need it :).
And most importantly, each example could be extracted to a ZIP and runnable by a user without any additional setup (TODO test this)
Currently I only moved the android, gradle, and maven example projects into the new folder.
Running
:promoteDevExamplescopies all /dev examples upwards, making them the new "release" versions.:syncExampleFoldersis run afterwards.Running
:syncAllExampleFolders(run automatically every:assemble) overwrites all relevant versions and properties in the examples from our main libs.versions.toml, gradle-wrapper.properties, .editorconfig, etc. This also works for any maven examples (see build-logic/src/.../buildExampleProjects for the specific implementation).GH actions was updated to run this command automatically, keeping our examples up-to-date :)
Running the Test task
:runBuildAllExampleFolders(run automatically every:testin debug mode, so on TC) builds all example projects usingTestBuildingExampleProjects. Each example project folder gets its own auto-generated Junit test so task dependencies can be set properly and TeamCity can run them in parallel.:syncAllExampleFolderstask, all dev Gradle Example projects getincludeBuild("../../../..")in settings.gradle.kts, which substitutes any DataFrame dependeny with our actual sources. This also makes working inside them from the IDE as easy as if it were a subproject :).android.sdk.diris unset. I modified TeamCity to provide-Pandroid.sdk.dir=%env.ANDROID_SDK_HOME%and it seems to work :) This gradle property is passed down to any example containing "android" (in any form) in its name. (This logic can change if needed):publishLocalto publish the artifacts to /build/maven before running the tests.