is this the best way to have written this

Question

gildor · Answer

What do you mean Make it more concise

xenoterracide · Answer

concise correct my first attempt at using this stuff

xenoterracide · Answer

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

xenoterracide · Answer

for example not convinced ``` configure lt CheckstyleExtension gt 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 · Answer

Look like everything is mostly fine You can avoid `buildscript` if use settings gradle to configure dependency management plugin that not published to <http plugins gradle org|plugins gradle org> You also can configure all the tasks inside tasks block but almost the same what you have now

gildor · Answer

all default plugins could be moved to `plugins` block ```plugin lt IdeaPlugin gt plugin lt CheckstylePlugin gt plugin lt MavenPublishPlugin gt plugin lt JavaLibraryPlugin gt ``` to ``` plugins idea checkstyle `maven publish` `java library` ```

gildor · Answer

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 lt StandardDependencyManagementExtension gt `

gildor · Answer

You don t need this line `plugin lt SpotBugsPlugin gt ` You already applied plugin in `plugins ` block

gildor · Answer

If you move checkstyle to plugins block you can use `checkstyle ` extension instead of `configure lt CheckstyleExtension gt `

gildor · Answer

same for `idea` plugin

gildor · Answer

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

gildor · Answer

gildor · Answer

And this settings gradle kts

gildor · Answer

gildor · Answer

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

xenoterracide · Answer

you also can t use latest in the plugins block right

xenoterracide · Answer

don t think I was pulling in the snapshot version

xenoterracide · Answer

and how do you know when to use backticks

xenoterracide · Answer

``` `java library` java `maven publish` checkstyle id com github spotbugs version 1 6 0 ```

xenoterracide · Answer

and when not to

gildor · Answer

autocomplete will help you understand

gildor · Answer

all the default gradle plugins available as static typed fields

gildor · Answer

gt 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 · Answer

gt 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 · Answer

So just delete all the code from settings gradle kts because io spring dependency management published to

gildor · Answer

gt and when not to You need backticks for characters that not valid for kotlin identifiers for example dash ` ` or space

gildor · Answer

anyway you can add backticks to each name if you want

gildor · Answer

gt 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 · Answer

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 · Answer

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

xenoterracide · Answer

basically benefits and detractors

xenoterracide · Answer

and I personally think the detractors are greater than the benefits

gildor · Answer

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

gildor · Answer

also it helps gradle to configure build faster

xenoterracide · Answer

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 · Answer

yes it cashes snapshots for 24 hours as I remember

gildor · Answer

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 · Answer

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 · Answer

thanks for the help though wink I appreciate it

gildor · Answer

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 · Answer

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

gildor · Answer

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 · Answer

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

xenoterracide · Answer

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 · Answer

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

gildor · Answer

Depends on library of course

xenoterracide · Answer

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 · Answer

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

gildor · Answer

yes sounds like a reasonable strategy

xenoterracide · Answer

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

gildor · Answer

again there are plugins for that too slightly smiling face

gildor · Answer

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

xenoterracide · Answer

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

gildor · Answer

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 · Answer

sure

xenoterracide · Answer

I might

xenoterracide · Answer

thanks for your help

gildor · Answer

You are welcome