is this the best way to have written this?

# gradle

[xenoterracide]

is this the best way to have written this?

[gildor]

What do you mean? Make it more concise?

[xenoterracide]

concise, correct? my first attempt at using this stuff

[xenoterracide]

also I obviously need to figure out why apt isn't working

[xenoterracide]

for example, not convinced

configure<CheckstyleExtension> {
    toolVersion = "8.4"
    sourceSets.addAll(java.sourceSets.filter { it.name != "test" })
}

is the best way to exclude tests, but I didn't see another way to do it, there was just a way to disable it in groovy

[gildor]

Look like everything is mostly fine.
You can avoid buildscript if use settings.gradle to configure dependency-management-plugin that not published to plugins.gradle.org

You also can configure all the tasks inside tasks{} block, but almost the same what you have now

[gildor]

all default plugins could be moved to plugins block:

plugin<IdeaPlugin>()
    plugin<CheckstylePlugin>()
    plugin<MavenPublishPlugin>()
    plugin<JavaLibraryPlugin>()

to

plugins {
   idea
   checkstyle
   `maven-publish`
   `java-library`
}

[gildor]

Also, when you move dependency-management-plugin to settings.gradle and use plugins block to apply it, you can configure it with generated extension dependencyManagement{}, instead of configure<StandardDependencyManagementExtension> {}

[gildor]

You don’t need this line:
plugin<SpotBugsPlugin>()
You already applied plugin in plugins{} block

[gildor]

If you move checkstyle to plugins block you can use:
checkstyle{} extension instead of configure<CheckstyleExtension>

[gildor]

same for idea plugin

[gildor]

I’ve played little bit with your config.
And what I get, not 100% that everything is correct, just a general idea

[gildor]

https://gist.github.com/gildor/0265477225f42b4083351a61544eff9d

[gildor]

And this settings.gradle.kts

[gildor]

https://gist.github.com/gildor/6fc6f08684aa55808bac2f5da86bac4f

[gildor]

anyway, you cannot use snapshot version with plugins block 😞 This is restricted for now

[xenoterracide]

you also can't use latest in the plugins block right?

[xenoterracide]

don't think I was pulling in the snapshot version

[xenoterracide]

and how do you know when to use backticks

[xenoterracide]

`java-library`
    java
    `maven-publish`
    checkstyle
    id(“com.github.spotbugs”) version “1.6.0"

[xenoterracide]

and when not to

[gildor]

autocomplete will help you understand

[gildor]

all the default gradle plugins available as static typed fields

[gildor]

you also can’t use latest in the plugins block right?

yes, just use not snapshot version and not dynamic, not sure why snapshot is restricted, because it can be helpful for testing and deubg

[gildor]

don’t think I was pulling in the snapshot version

Oh, I see, not sure like laste.version works. If you just need release you can remove all the code from settings.gradle.kts and use release

[gildor]

So, just delete all the code from settings.gradle.kts, because io.spring.dependency-management published to plugins.gradle.org: https://plugins.gradle.org/plugin/io.spring.dependency-management

[gildor]

and when not to

You need backticks for characters that not valid for kotlin identifiers (for example dash - or space)

[gildor]

anyway, you can add backticks to each name, if you want

[gildor]

you also can’t use latest in the plugins block right

It’s good practice actually, because you have repeatable builds and faster, because gradle doesn’t check for a new version all the time.

[xenoterracide]

I'm sketchy on that last bit mostly because currently it's looking like update headache, but eventually I'm going to figure out how I can write a plugin to manage these plugins in a more unified way

[xenoterracide]

it also means I won't know as soon as a new release breaks something

[xenoterracide]

basically benefits and detractors

[xenoterracide]

and I personally think the detractors are greater than the benefits

[gildor]

Yes, but do you really want to get broken build eventually, just because new version released

[gildor]

also it helps gradle to configure build faster

[xenoterracide]

depends on the thing... (and whether I can choose to do something like 1.^ instead of just latest, so I can theoretically conform to an api, but get bugfixes. and I can see the point on the configuration, but even when doing snapshots IIRC gradle caches for a while?

[gildor]

yes, it cashes snapshots for 24 hours, as I remember

[gildor]

anyway, you cannot use dynamic version for plugins now, only on buildscript that works bad with kotlin-dsl and will probably be deprecated in the future. If you have a good case about dynamic dependencies for plugins block, you should probably report to Gradle - https://github.com/gradle/gradle/issues

[xenoterracide]

yeah, so I'd expect the same thing of requesting latest in a plugin, only check if greater than whatever.

having worked with Perl, NPM, and maven, gradle build systems, I'd say perl had the best regarding dealing with updates, in part due to cpantesters that were able to run all kinds of wonky versions against all other kind of wonky versions. So you'd see more real world usage. Where in java everyone uses fixed versions and then you need something like a BOM to actually sort out which versions work together. NPM on the other hand has the worst language dependency management, being the only one where you have do something like while failing try again until it works.

java's stuff is good, just seems to be a little more at risk for not working in various configurations, and harder to keep on top of security patches

[xenoterracide]

thanks for the help though 😉 I appreciate it

[gildor]

About security patches there is a few plugins for gradle that check it for you and report if you build app using dependency with security problem

[xenoterracide]

interesting thing about security patches is that only works if they've been reported as security issues

[gildor]

but don’t think that it make a lot of sense for plugin, because plugin is local only thing and in 99% doesn’t affect your application

[gildor]

Yes, they use some DB of security issues in different java libraries

[xenoterracide]

been a few issues that were fixed in the past couple of years, that made headlines for being fixed, but nobody realized they were security issues so they weren't backported

[gildor]

To be honest, I don’t think that use the latest, just released version of library is the most secure way

[gildor]

Depends on library, of course

[xenoterracide]

and for example a security bug I recently helped get fixed, and I said it was a vuln, also wasn't reported with a CVE, reminds me, I need to test that to see if it's really fixed

[xenoterracide]

I guess I just like to roll with the latest major version having seen the behavior of many vendors

[gildor]

yes, sounds like a reasonable strategy

[xenoterracide]

and I can see that argument for plugins except, findbugs does find security issues

[gildor]

again, there are plugins for that too 🙂

[gildor]

I mean who checks you dependency versions explicitly and report if you use old one

[xenoterracide]

well I mean spotbugs finds issues in "my" code 😉 like it can find some variants of sql injection, and if they were to add a new one of those

[gildor]

Anyway, I agree that for some use cases strategy with the latest version can be useful, so would be good to report this case to Gradle

[xenoterracide]

sure

[xenoterracide]

I might

[xenoterracide]

thanks for your help

[gildor]

You are welcome