kelemen / netbeans-gradle-project

This project is a NetBeans plugin able to open Gradle based Java projects. The implementation is based on Geertjan Wielenga's plugin.
169 stars 57 forks source link

Add "Dependencies" node under "Build Scripts" node #232

Open gallardo opened 9 years ago

gallardo commented 9 years ago

Currently, the gradle project view has a Build Scripts node under which the Project and Gradle Home nodes lists the build script and its configuration. What I'm missing is a Dependencies node for the buildscript, similar to the Dependencies node for all project compilations. Notice that the "buildscript" dependencies are not accessible under gradle.project.configurations and thus are not being shown for the moment.

Example:

import com.helger.datetime.CPDT

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.helger:ph-datetime:4.2.0'
    }
}

// Silly tasks to assert that com.helger.datetime.CPDT (declared as buildscript
//  dependency) is resolved (#231)
task testBuildscriptDeps <<{
    println CPDT.class
}

Possible project model tree: image

I could also imagine the dependencies for the build script being listed under dependencies, under a new 'buildscript` node.

kelemen commented 9 years ago

I'm not sure that I can list those dependencies because those dependencies are local to a particular .gradle file and I don't know about any API of Gradle which would let me retrieve it (i.e., I would need the build script to cooperate and share those dependencies). Not to mention that there could be other applied .gradle files having different dependencies.

Personally, I try avoiding too complex code (requiring additional dependencies) in the build script. Any complex logic is more maintainable if kept in the buildSrc project. There you have all your dependencies listed and better tool support as well.

gallardo commented 9 years ago

I don't know about any API of Gradle which would let me retrieve it

I cannot suggest anything(*) to overcome this problem or to improve the situation. I was hoping that the plugin copes with those internals, so I don't have to reverse-engineer the build script and study the gradle documentation site.

(*) I'm afraid I'm just a gradle user by necessity. Though I had devoted much more time than I wanted to the build scripts of the project I'm working on, Gradle is a big conventions over configuration beast that still escapes my technical skills in many areas.

I try avoiding too complex code (requiring additional dependencies) in the build script

I very much support this attitude, but when opening external projects you have no choice. If this plugin cannot cope with these details, then it is up to the user to understand where do dependencies for the build script come from.

Still, this doesn't render the plugin unusable, so I would flag this report as "enhancement" and let it rest until popular demand (if any) suggest to work on it.

kelemen commented 9 years ago

Actually, this is not only a problem for this plugin but script files as well. That is, it usually surprises people that a script file applied with apply from: 'myscript.gradle' cannot use the dependencies of the calling script file.

There is the project.buildscript.classLoader property but I can't imagine that to be good (altough probably better than the current one) because each .gradle might define its own dependencies (there is no single dependencies list which can be applied to all .gradle files).