pablisco
02/13/2020, 12:31 PMFleshgrinder
02/13/2020, 12:36 PMapi("org.openjdk.jmh", "1.23") { api("jmh-core"); api("jmh-generator-annprocess") }
(just using JMH here because I have a build file with it directly in front of me).pablisco
02/13/2020, 12:42 PMOleg Yukhnevich
02/13/2020, 1:45 PMFleshgrinder
02/13/2020, 1:47 PMbuildSrc
approach is a well known one but it comes with major drawbacks and makes the overall handling actually more complicated than it has to be.Oleg Yukhnevich
02/13/2020, 1:50 PMbuildSrc
is really very usable, so I can very easy configure every module similar and configurable
So, it's project related I thinkFleshgrinder
02/13/2020, 1:57 PMJavier
02/13/2020, 2:01 PMpablisco
02/13/2020, 2:02 PMOleg Yukhnevich
02/13/2020, 2:03 PMwe can anyways directly use a stringBut, if to think, we don't always now string exactly, rly
IntelliJ will be as it has big troubles with Kotlin Scriptwith 1.3.70 kotlin and 6.x gradle - it's really now much faster, then before
Versions are hardcoded for dependenciesin my lib versions can be easily overridden, if it needed just take any dependency, and use
.version("1.5.0")
or `.version(project.properties["some_version"])
I never found the right strategy that is understood by everyone and easy to use.Can you also share you tries and drawbacks of them?
Javier
02/13/2020, 2:38 PMOleg Yukhnevich
02/13/2020, 2:39 PMplugin
is used 🙂
here: https://github.com/whyoleg/ktd/blob/clients-rework/gradle/wrapper/gradle-wrapper.properties
and it's 6.1Javier
02/13/2020, 2:44 PMOleg Yukhnevich
02/13/2020, 3:38 PMplugin
configuration, and it's gradle version not so needed
So, if u look at second repository, which I sent, there this plugin is used as build script classpath dependency in settings.gradle.kts and in buildSrc, and it works really well with gradle 6pablisco
02/13/2020, 7:27 PMFleshgrinder
02/13/2020, 7:42 PMbuildSrc
approach. At that time many people came to this solution and everyone was posting about it everywhere. The issues mentioned above and the fact that many people were extremely confused by buildSrc
made it a failure as well.
The next thing I did was also in conjunction with buildSrc
but without types, I kept the strings. I find it hard to explain but can post it later. It's actually pretty neat.
What I mostly use today is https://plugins.gradle.org/plugin/nebula.resolution-rules combined with platform
. Not many things require any versions anymore with this approach beause I'm mostly working with Spring. Of course there are still many projects that have no BOM (😠) but in those cases Nebula RR can mitigate it. It has its limitations too https://github.com/nebula-plugins/gradle-resolution-rules-plugin/issues/97 … so at the end of the day one always ends up with complicated Gradle scripts to get those wild Java dependencies nicely aligned.Oleg Yukhnevich
02/14/2020, 7:19 AMI'll try to post it laterWill wait to try it 🙂 Any git repo exists to track?
common/jvm/js/native
suffix
With my approach it one line, which, really, decrease amount of code needed for simple dependency managementFleshgrinder
02/14/2020, 7:25 AMOleg Yukhnevich
02/14/2020, 7:26 AMGradle metadata
is the first step, to create such solution, so in future, I believe smth will beFleshgrinder
02/14/2020, 7:29 AMpablisco
02/14/2020, 4:02 PM_modules.kt
inside buildSrc
. This file is determined by the project's file structure. So it should be less friction when adding or extracting modules.Oleg Yukhnevich
02/14/2020, 5:18 PMpablisco
02/14/2020, 5:28 PMapi(local.core)
I'm also considering adding a separate plugin to add groovy support for projects that may have a mix of both languages (with large projects and teams it's not trivial to migrate them all at once)Oleg Yukhnevich
02/14/2020, 6:38 PMmetadata {
dependenciesMain {
api(ProjectModules.core)
}
}
metadata is MPP target from kotlin pluginProjectModules
is auto generated file in buildSrcpablisco
02/20/2020, 1:47 AMOleg Yukhnevich
02/20/2020, 6:18 AMFleshgrinder
02/20/2020, 7:58 AMpablisco
02/20/2020, 8:41 AM