Separate build from project dependencies

[aalmiray]

Currently all dependencies appear on the same block. It would be good to have an option to separate them.

[ben-manes]

This is vague. Do you want it grouped by module (#70, #101)? Or do you want run it on each project and not show include its children (current level only)?

The text report was written assuming the plugin was applied only at the top level, so the entire tree is evaluated. This way if the dependencies are defined centrally (e,g. gradle/dependencies.gradle) the master file can be updated directly. That is often a best practice for large builds so that each module can declare its dependencies without having to restate the full coordinate.

[aalmiray]

Have a look at a sample report for a moderate sized project

The following dependencies are using the latest milestone version:
- com.github.ben-manes:gradle-versions-plugin:0.15.0
- com.google.code.findbugs:jsr305:3.0.1
- com.google.guava:guava:22.0
- com.h2database:h2:1.4.196
- com.jidesoft:jidefx-fields:0.9.1
- com.miglayout:miglayout-javafx:5.0
- com.thoughtworks.xstream:xstream:1.4.10
- commons-io:commons-io:2.5
- de.codecentric.centerdevice:javafxsvg:1.2.1
- de.ppi.dbunit.datasetbuilder:dbunit-datasetbuilder:1.4
- eu.mihosoft.jfx.scaledfx:scaledfx:0.4
- io.reactivex:rxjava-string:1.1.1
- jaxen:jaxen:1.1.6
- junit:junit:4.12
- log4j:apache-log4j-extras:1.2.17
- log4j:log4j:1.2.17
- net.nemerosa:versioning:2.6.1
- nl.javadude.gradle.plugins:license-gradle-plugin:0.11.0
- org.apache.commons:commons-collections4:4.1
- org.apache.commons:commons-math3:3.6.1
- org.asciidoctor:asciidoctor-gradle-plugin:1.5.3
- org.awaitility:awaitility:3.0.0
- org.bitbucket.shemnon.javafxplugin:gradle-javafx-plugin:8.1.1
- org.codehaus.griffon.plugins:griffon-glazedlists-javafx:1.3.1
- org.codehaus.griffon:gradle-griffon-plugin:2.12.0
- org.codehaus.griffon:griffon-core-compile:2.12.0
- org.codehaus.griffon:griffon-core-java8:2.12.0
- org.codehaus.griffon:griffon-core-test:2.12.0
- org.codehaus.griffon:griffon-core:2.12.0
- org.codehaus.griffon:griffon-guice:2.12.0
- org.codehaus.griffon:griffon-javafx:2.12.0
- org.dbunit:dbunit:2.5.1
- org.fxmisc.easybind:easybind:1.0.3
- org.fxmisc.undo:undofx:1.3.0
- org.fxmisc.wellbehaved:wellbehavedfx:0.3
- org.hamcrest:hamcrest-all:1.3
- org.jdeferred:jdeferred-core:1.2.6
- org.kordamp.gradle:jdeps-gradle-plugin:0.2.0
- org.kordamp.gradle:stats-gradle-plugin:0.2.0
- org.kordamp.jipsy:jipsy:0.4.1
- org.mockito:mockito-core:2.8.9
- org.projectlombok:lombok:1.16.18
- org.slf4j:slf4j-api:1.7.25
- org.slf4j:slf4j-log4j12:1.7.25
- org.slf4j:slf4j-simple:1.7.25
- org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.5
- org.springframework.data:spring-data-jpa:1.11.6.RELEASE
- org.springframework:spring-aop:4.3.10.RELEASE
- org.zeroturnaround:zt-exec:1.9
- pl.pragmatists:JUnitParams:1.1.0

There are 6 gradle plugins listed in this report but they may appear in any order (related to #165). I think it would work best if all of these dependencies (and their transitive deps too) were to be grouped.

[ben-manes]

I see, you want plugins (buildscript configuration) separately reported from the project dependencies? Would that be grouped by resolution status or all be flattened? There are other report styling changes requested, e.g. breadcrumbs and configuration, so it gets messy if all were implemented. I'm inclined to let people generate nicer reports based on the xml/json.

Is this request because your plugins block entries are separately defined from your centralized dependency configuration? If so, I'd recommend sticking with buildscript which is as succinct and doesn't conflict. For example,

buildscript {
  apply from: "${rootDir}/gradle/dependencies.gradle"

  repositories {
    maven { url 'https://plugins.gradle.org/m2' }
    mavenCentral()
    jcenter()
  }

  dependencies {
    classpath gradlePlugins.values()
  }
}

Then just walk through your dependencies.gradle to update versions based on the report.

[aalmiray]

I prefer the buildscript block over plugins which IMHO is implemented halfway anyway. All this being said, do plugins get listed in the same "block" when you use your style of configuration? I understand that other users would like to see their own conventions being implemented in their reports, thus is it possible to externalize the strategy used to organized dependencies? That way anyone can hook in their own convention.

[ben-manes]

If you look at my dependencies.gradle example, that's what I do for internal projects too. Then I walk the versions declarations, since its pretty obvious what matches the full coordinate.

There is a json/xml/closure hooks contributed by others, so I haven't used them personally. I know some have integrated it into their CI for custom reports, e.g. see gradle-update-notifier.

Right now the xml/json reports don't provide that level of details, but I wouldn't be opposed to the addition if backwards compatible.

Long term I keep hoping that Gradle will bake this feature in and offer the more advanced capabilities.

[vanniktech]

@aalmiray if we would restore the sorting - https://github.com/ben-manes/gradle-versions-plugin/issues/165 - would this help and possibly close this issue?

[aalmiray]

@vanniktech sorting dependencies will certainly help, however it does not fix the underlying issue. One thing is to sort dependencies by groupid/artifactid, another is by their responsibilities (build deps vs project deps).

[grv87]

Project dependencies include only compile, runtime and similar dependencies for compilation of the project per se. All other dependencies, including plugins, buildscript dependencies, codenarc, compileTest etc. configurations are build dependencies.

It would be good if plugin could separate them. Maybe, DependencyUpdatesTask could have a property to filter configurations, so that user could create several task instances with different settings.

[Vampire]

It's not that easy. Basically you can have any amount of configurations that are project dependencies and any amount of configurations that are build dependencies, latter both in the buildscripts block and also in the normal block e. g. added by Gradle plugins. It might be a good default to have assumptions on what is project and what build dependency, but it should be configurable which is considered what, so that it can be customized to any build logic someone comes up with.

[grv87]

In my new plugin I've separated build tools and dependencies by configuration name, here. Task have closure property which by default uses this code. But it could be reconfigured by the user.

[Vampire]

From a first very brief look I'd say you miss iterating the source sets and iterating their associated configurations.

[ben-manes]

That's nice @grv87, but of course has some hard coded magic useful for the common-case. I think our best option might be to add a configuration list in the json/xml/code output for where the dependency update was found. Then it would be up to consumers of those report types to utilize it as best fit. But it would be too spammy for the text report, of course, so we'd not organize by that.

Would that be helpful or just punting without solving the root problem?

[grv87]

As user, I would want to have separate tasks for different groups. I don't need to see specific configuration in the report, I just need several reports.

But @aalmiray may have something else in mind.