gradle / gradle Goto Github PK

Context

Forum Post

Many users would like to send their own messages to the progress logger. Also see elastic/elasticsearch#18935

Native build on a maching with Visual Studio 2015 doesn't work (probably because CRT location changed). I noticed this issue in JIRA and even a proposed fix (PR) a long time ago but unfortunately this still isn't fixed

Expected Behavior

Buildling with VS toolchain should work when VS15 is instaled

Current Behavior

doesn't find stdio.h (or something like that)

Context

Since I have VS15 installed on my machine (for a different project) and I also need to work on a Gradle/Java project, I need to run the Gradle build in a different VM which is a pain.

Steps to Reproduce (for bugs)

Your Environment

• Build scan URL:

Hi
When building a NativeExecutableSpec with a specific baseName, the release build produces the proper baseName executable while the debug build produces an executable with the default baseName

Expected Behavior

Both build (debug, release) should honor the baseName specified in the script
The binaries produced are

Z:\git\cpp_gradle\build\exe\main\debug\main.exe
Z:\git\cpp_gradle\build\exe\main\release\foo.exe

instead of

Z:\git\cpp_gradle\build\exe\main\debug\foo.exe
Z:\git\cpp_gradle\build\exe\main\release\foo.exe

Current Behavior

Only the second build is honoring the baseName specification in the build script. When there are more than 2 builds as for exemple with NativeSharedLibrary, only the first build gets the default name instead of the baseName.

        hello(NativeLibrarySpec) {
            binaries.all {
                cppCompiler.define "HELLO_EXPORT"
                baseName 'bar'
           }

produces

Z:\git\cpp_gradle\build\libs\hello\shared\debug\hello.dll
Z:\git\cpp_gradle\build\libs\hello\shared\release\bar.dll
Z:\git\cpp_gradle\build\libs\hello\static\debug\bar.lib
Z:\git\cpp_gradle\build\libs\hello\static\release\bar.lib

Context

I am trying to produce binaries for VS2015 with specific base name

Steps to Reproduce (for bugs)

1/ Clone this git repo: https://github.com/carlosvin/cpp_gradle/
2/ Edit the build.gradle by adding baseName 'foo' as

        main(NativeExecutableSpec) {
            binaries.all {
                lib library: "hello"
        baseName 'foo'
            }
        }

Your Environment

Z:\git\gradle>gradlew --version

Gradle 3.3-20161013000043+0000

Build time: 2016-10-13 00:00:43 UTC
Revision: 021d872

Groovy: 2.4.7
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.7.0_51 (Oracle Corporation 24.51-b03)
OS: Windows 7 6.1 amd64

Remove Gradle GUI from the codebase, documentation and website (e.g. https://gradle.org/why/build-reporting/).

Note that this is also related to this is removing the OpenAPI bits (which the GUI depends on).

Performance related: HttpResourceAccessor isn't currently thread safe (that solution has been introduced in this commit).

It seems that Gradle might already access that code concurrently for example at this location.

Expected Behavior

When using the Announce plugin on Mac OS we should use system notifications.

Current Behavior

We try to use Growl via Apple script which does not if Growl is not installed and makes the build fail. This also makes tests in :announce fail and as a consequence runnning gradlew build for the build tool itself results in an error.

Steps to Reproduce (for bugs)

Run ./gradlew build on Mac OS. Then BuildAnnouncementsPluginIntegrationTest will fail.

Your Environment

• Build scan URL: https://scans.gradle.com/s/acurmrrynyewa

Implementation

Using system notification via Apple script seem to be easy. We only would need to change AppleScriptBackedGrowlAnnouncer.

When finishing Gradle 3.0 we agreed that we should deprecate many things early in the 3.x release cycle to be able to remove those for 4.0. There is quite a lot of documentation of what should be done for 4.0.

We should create a Gradle 4.0 design spec, document there what should be removed in 4.0 and deprecate all those things in the process

Dependency resolve errors fail in IDEA Gradle import with a very bad error message:

The stack trace can be seen in the idea.log file: https://gist.github.com/lhotari/001603e567bb3d00f2fb558cb8be1f15 . Importing this project to Idea reproduced the problem: https://github.com/lhotari/gradle-tapi-NotSerializableException-bug .

Unserializable exceptions are supposed to be handled, and replaced with a placeholder. It looks like that’s broken when the exception propagates out of a ⁠⁠⁠⁠BuildAction⁠⁠⁠⁠.

This problem has a JIRA issue:
https://issues.gradle.org/browse/GRADLE-3307

Code review

https://code-review.gradle.org/cru/REVIEW-6309

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Other Java tools are experiencing a problem with looking up the local hostname on macOS Sierra (10.12). Here's a longer description of the problem: https://thoeni.io/post/macos-sierra-java/

Expected Behavior

Local host look-up should be speedy, or if not, cached.

Current Behavior

I suspect this causing a problem here:
https://discuss.gradle.org/t/gradle-always-execute-creating-new-in-memory-cache-for-repo-maven-when-i-build-project-i-configurated-org-gralde-daemon-true-in-gradle-properties-the-command-line-properties-like-org-gradle-daemon-true-are-ignored/20080

Context

We have an uncached hostname look-up here:
https://github.com/gradle/gradle/blob/master/subprojects/resources-http/src/main/java/org/gradle/internal/resource/transport/http/ntlm/NTLMCredentials.java#L64

We have a cache in InetAddressFactory for this look-up that we could re-use. This has a large impact on builds with many repositories.

Steps to Reproduce (for bugs)

This happens always.

Your Environment

macOS Sierra

@big-guy commented on Fri Aug 19 2016

I found this in PlayRun, but there may be other tasks that have this problem.

runtimeClasspath is annotated as an @InputFiles:
https://github.com/gradle/gradle/blob/master/subprojects/platform-play/src/main/java/org/gradle/play/tasks/PlayRun.java#L67-L67

It has a setter, but no getter, so we don't see this as an actual input because we look for getters. This means we don't get an error message when it's null.

I don't know if it makes sense to change the way we search for annotations or just add a validation to the java-gradle-plugin validator that looks for this scenario.

As a preparation for removing the leftShift operator on Task in Gradle 5.0 we need to deprecate it in Gradle 3.x since it is widely used. For this to be complete we also need to remove calls from our examples, the documentation and tests.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Expected fixes: #748 and #710

• Update release notes
• Get verification from submitters

The first preview of Findbugs supporting Java 9 has just been released: https://github.com/findbugsproject/findbugs/releases/tag/3.1.0_preview1

All of our code quality plugins (including the FindBugs plugins) resolve the FindBug dependency as external dependency via GAV. Currently, the FindBugs version 3.1.0 (supporting Java 9) is not available on Maven Central/JCenter yet. I asked about an ETA for the publish date but it looks like it is going to take a while as it also relies on ASM 6 and BCEL 6 preview builds.

At the moment I don't think it's worth trying out the SNAPSHOT version of FindBugs as it would require additional changes to the FindBugs plugin to be able to point to local library files. Also we'd need to provide those libraries with the Gradle distribution which we definitely do not want to do.

As part of this FindBugsIntegrationTest needs to be fixed for Java 9

Currently we track 1.8, i.e. major and minor version for JavaCompile.

We should also track

• full version number including build number
• vendor
• Make sure we track it for GroovyCompile here:

  gradle/subprojects/language-groovy/src/main/java/org/gradle/api/tasks/compile/GroovyCompile.java

  Line 132 in 678fc22

  return JavaVersion.current().getMajorVersion();

• Remove vendors as inputs added here 06c5da7

https://discuss.gradle.org/t/gradle-3-1-jansi-classdefnotfound/19978

Gradle Version: 3.1
Operating System and JVM version: Linux primarily any JVM
Is this a regression? If yes, which version of Gradle do you know it last worked for? Yes, worked in 3.0

With the upgrade to jansi 1.13 a native library now is attempted to be extracted from the bundled jar and then loaded into memory. Unfortunately, this can fail with Could not initialize class org.fusesource.jansi.internal.CLibrary if there is any issue loading that library.

By default this library attempts to extract itself to java.io.tmpdir, which can often be mounted under linux as noexec, and under those conditions it will fail with the "Could not initialize class org.fusesource.jansi.internal.CLibrary" error.

This error can be simulated on windows or linux by simply modifying the DEFAULT_JVM_ARGS for the gradle or gradle.bat scripts and setting -Djava.io.tmpdir=somedirectory-that-does-not-exist

Fortunately, there is also a -Dlibrary.jansi.path that can be set, as altering java.io.tmpdir is only the fallback if that isn't explicitly set to something.

The failure occurs in ConsoleConfigureAction.java as all other references to jansi classes do not trigger any native library loading. Ideally the library.jansi.path system property would be assigned just before the AnsiConsole.wrapOutputStream() calls. It seems that setting it to gradleUserHome makes sense, unfortunately the two existing classes that provide that lookup capability are not visible to the logging component at present (and they probably shouldn't be either).

Unfortunately, attempting to pass in system properties via gradle.properties doesn't work, and attempting to simulate with commandLine argument settings for system properties forces a daemon to start and the actual failure is not displayed other than the daemon failing to start.

The Jetty plugin has been deprecated with Gradle 3.0. The plugin including all its tests needs to be removed from the Gradle code base. Any testing coding code that relies on the Jetty plugin needs to be changed to use a different solution.

Expected Behavior

Delete the plugin code under jetty subproject and anything in the Gradle core infrastructure that uses it.

Current Behavior

Users will have to use the external Gretty plugin.

Context

The Jetty plugin in its current form does not provide a good user experience. It uses a very old version which is not configurable. Users expect more functionality of the plugin.

Your Environment

All environments.

For instance:

// ~/.gradle/init.d/buildScan.gradle
initscript {
  repositories {
    maven { url = uri("https://plugins.gradle.org/m2") }
  }
  dependencies {
    classpath("com.gradle:build-scan-plugin:1.7.1")
  }
}

Expected Behavior

When generating the HTML dependency report it would make sense to directly print the url of the generated html file on the build output as a user usually directly wants to see the report afterwards.

Current Behavior

apply plugin: 'project-report' in build.gradle then run dependencyReport
This just prints BUILD SUCCESSFUL without any URL to the actual report.

Context

I want to be able to quickly view the report after I run the dependencyReport task and I should not have to guess where it is under the $buildDir

Current Behavior

Daemons running leaky code can accumulate open file descriptors and fail at some point with some Too many open files error.

Expected Behavior

Like daemons are expired according to memory/gc pressure, they should be expired when they keep a too large number of open file descriptors.

Environment

On all systems derived from unices, JMX provide MaxFileDescriptorCount and OpenFileDescriptorCount attributes that could help implement.
On Windows these attributes are absent ; we either need to not apply this expiration strategy or find a way to get the info.

Note that leaky file descriptors in code run by daemons can be a bigger problem on Windows given it's exclusive locking behavior and can prevent such an expiration strategy to bring real benefit.

I thought we had already done this at some point.

We already have project.copy, we should provide the Sync-equivalent.

This is essential for any sort of language support. Without this being public (or rather some sort of public factory), it's almost impossible to make a new language SourceSet. Note that the new model has a factory for this, but there is not one for the current model.

For some features the Jigsaw module java.xml.bind is required. This is not exposed imported by default, see https://bugs.openjdk.java.net/browse/JDK-8157670 . Currently we do not know if more modules are required.

We need to add the modules to the JVM running Gradle/doing testing via the JVM option -addmods.

It looks like Gradle is not executing/recompiling the Dependency.metaClass.environmentMarkers = bla in the below sections.

If you were to execution this build script:

Dependency.metaClass.environmentMarkers = { String... markerStrings ->
  println delegate
}

configurations {
  compile
  }
repositories {
  mavenCentral()
}
dependencies {
  compile('junit:junit:4.11') { environmentMarkers('sss') }
}

Then add a println in the closure, with the daemon running it would not print the second line. If you stop the daemon it will pick up the update on the first run, but then cache the closure again.

Not everything that can be stored in cache should be stored in cache; we could offer different (configurable) strategies for deciding when to store the results of some task (size < 10 MB, size / time ratio < constant etc.). We could allow strategies for deciding whether to ask the cache backend for a stored result, too.

Difference between invocations of System.currentTimeMillis() cannot be trusted to calculate durations because it can produce a negative value due to how CPU clock synchronization occurs in various environments. See http://steveloughran.blogspot.fi/2015/09/time-on-multi-core-multi-socket-servers.html

Anytime we do this:

long start = System.currentTimeMillis();
… do stuff …
long timePassed = System.currentTimeMillis() - start;

We should use:

long start = System.nanoTime();
... do stuff ...
long timePassed = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);

For actions that take fewer than 15 microseconds, you’ll sometimes notice that the difference between two reads of nanoTime() might be 0; however, it won’t produce negative values because it is always going to be monotonically increasing.

Expected Behavior

All durations calculations (e.g. those for build times) should never produce a negative value.

Current Behavior

We sometimes encounter negative durations during builds that negatively affects logic and produces inaccurate logs.

Context

This causes sporadic failures on Gradle CI, at the very least.

In a project with the war plugin applied, tasks that take src/main/webapp as an input directory fail to correctly watch this directory when run as a dependency of the classes task. There's probably a non-plugin-specific cause, but I can't pinpoint it.

Expected Behavior

When modifying a file under src/main/webapp, I expect tasks declaring this directory as an input directory to be retriggered when they are part of a continuous build, regardless of whether they are run as a target task or as a dependency of some other task.

Current Behavior

When such a task is run as a dependency of the classes task, changes under src/main/webapp do not retrigger the build.

Context

In a project using the war plugin, I am trying to automatically run a custom task for JS/CSS processing when src/main/webapp is changed, so that I can quickly and easily see code changes in the browser.

Steps to Reproduce (for bugs)

• Clone https://github.com/delego-wlritchi/gradle-watch-bug
• Run ./gradlew classes -t
• In a new terminal, modify a file under src/main/webapp. Observe that the build is not retriggered.
• Now modify the toplevel file. Observe that the build is retriggered as expected.

Your Environment

• Gradle Version: 2.11 through 3.2-rc-1
• Last worked correctly in: 2.10
• Operating System: Arch Linux 64-bit
• JVM version: OpenJDK 1.8.0_102

We have public factory methods for creating NamedDomainObjectContainers, we should have something similar for polymorphic containers.

The PolymorphicDomainObjectContainer is part of the public API and a powerful tool for building extensible DSLs. Unfortunately, there is no public way to create one. We should add Project.polymorphicContainer(Class baseType)

We merge the concepts of NamedDomainObjectContainer and PolymorphicDomainObjectContainer. Every container can be and should be polymorphic.

Also consider the case where one just wants to add something to the base/default type.

e.g., if your container is any type of Widget and by default there's a DefaultWidget, but someone could implement a SpecializedWidget:

widgets {
   foo {} // implicit type DefaultWidget
   bar(DefaultWidget) {} // explicit
   special(SpecializedWidget) {} // explicit
}

Something we should also think about is a way to register a factory for all containers, as is available in the software model. This allows others to reuse the types in locations beyond where the plugin author happens to register factories.

The change adds a new ChangeType value REPLACED (reference: 0a4a3bb). This leads to two issues:

FileChange has not been updated to provide a isReplaced() method so plugins cannot query for this kind of file change. Because OrderSensitiveTaskFilePropertyCompareStrategy has been changed to exclusively use the new status instead of MODIFIED some file changes cannot be detected by new task implementations.

However a bigger problems is that existing plugins that go through IncrementalTaskInputs.outofDate looking at isModified() will also always miss the files that use the new status. The only fix is to release a new version of the plugin (after the new API is fixed with a new isReplaced() method).

In order to be compatible, I believe Gradle should make these replaced files return true for both isModified() and isReplaced(). This require some more refactoring as FileChange only support a single ChangeType.

The Gradle plugin for Android is failing some of its tests on 3.1 because of this.

• JIRA issue: GRADLE-3577
• Internal review: REVIEW-6345

Effectively, a way to have a build always apply an init script available via a HTTP URL when executing. Imagine a line item in wrapper.properties or similar with the location of one or more scripts. This is a long desired feature with many uses, but in our context would be leveraged to at least provide the logic to build the custom plugin repo definition.

Example: apply from: "https://myservice.example.com/foobar"

• Look into ordering of plugin repositories resolution
• Respect caching headers of given remote resource
• Expired resource should still be used in --offline mode

Plugin authors like myself need incremental tasks that preserves source directory structure in the output.

For example:

Input

style.css
vendor/bootstrap.css

Output

$buildDir/style.min.css
$buildDir/vendor/bootstrap.min.css

I would like this test to pass using IncrementalTaskInputs. See here also.

Since VisitableURLClassLoader does not override any methods related to class loading and does not hold any state, it should be registered as parallel capable.
I see a lot of locking in VisitableURLClassLoader.loadClass in one of my tasks (that compiles a set of Groovy classes).
See https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent, https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html.

Gradle and all of it's plugins/tasks should run while on JDK 9

An overview of what is still not working are Unit and Integration tests which do not pass on Java 9. Currently, there tests are excluded by annotating with

@Requires(FIX_TO_WORK_ON_JAVA9)

Expected Behavior

This forum post expose a common scenario that is well documented in Gradle documentation.

Current Behavior

The DSL documentation for Gcc as well as Clang lack documentation of publically available APIs from GccCompatibleToolChain. The user guide also lack documentation for this specific scenario.

Context

The friction level for new developers is higher than it should be.

Steps to Reproduce (for bugs)

N/A

Your Environment

See forum post: https://discuss.gradle.org/t/how-to-make-gradle-choose-a-different-version-of-c-compiler/20181

Expected Behavior

Given the following script:

task a {
  finalizedBy 'b'
}
task b {
  finalizedBy 'b'
}

Invoking the ./gradlew a should detect a cycle.

Current Behavior

The previous code will throw an IndexOutOfBoundException:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
    at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.onOrderingCycle(DefaultTaskExecutionPlan.java:425)
    at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.determineExecutionPlan(DefaultTaskExecutionPlan.java:287)
    at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.ensurePopulated(DefaultTaskGraphExecuter.java:202)
    at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:109)
    at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
    at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
    at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
    at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
    at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
    at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
    at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
    at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:197)
    at org.gradle.internal.Factories$1.create(Factories.java:25)
    at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
    at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53)
    at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:194)
    at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:36)
    at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:118)
    at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:112)
    at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
    at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63)
    at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
  ...

Context

Tested on Gradle 3.2-rc-1, not a regression as the code fail all the way back to Gradle 1.12.

Steps to Reproduce (for bugs)

./gradlew a with the provided sample.

In coordination with @ghale and @oehme, a list of oft-used internal APIs that plugin authors and build masters routinely use.

We must empower the community by giving them public, well-supported, and forward-compatible APIs for their build scripts and plugins.

Some of these are blocking the next versions of the Spring Boot plugin, various language plugins (including PyGradle), and web plugins

We need a mode that when enabled will put the cached results into $buildDir/cached-results/$task.name or something, execute the task locally, and don't upload the results to cache. Then the user can compare the actual results with the cached ones.

Or extract them to build-cached with the same structure as $buildDir. Might be tricky to calculate a different hierarchy.

In a script in which the configured toolChain isn't available to Gradle, the visual-studio plugin won't generate the solution and lifecycle tasks.

Expected Behavior

The visual-studio plugin should either always generate all tasks, regardless of the available toolchains, or report a useful error.

Current Behavior

On a machine without GCC, with the following code

apply plugin: 'cpp'
apply plugin: 'visual-studio'

model {

    toolChains {

        gcc(Gcc) {

        }

    }

    components {

        TestProject(NativeLibrarySpec) {

        }

    }

}

gradle tasks --all output is

Build tasks
-----------
assemble - Assembles the outputs of this project.
build - Assembles and tests this project. [assemble, check]
clean - Deletes the build directory.
TestProjectSharedLibrary - Assembles shared library 'testProject:sharedLibrary'.
    linkTestProjectSharedLibrary - Links shared library 'testProject:sharedLibrary'
TestProjectStaticLibrary - Assembles static library 'testProject:staticLibrary'.
    createTestProjectStaticLibrary - Creates static library 'testProject:staticLibrary'

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'test'.
components - Displays the components produced by root project 'test'. [incubating]
dependencies - Displays all dependencies declared in root project 'test'.
dependencyInsight - Displays the insight into a specific dependency in root project 'test'.
help - Displays a help message.
model - Displays the configuration model of root project 'test'. [incubating]
projects - Displays the sub-projects of root project 'test'.
properties - Displays the properties of root project 'test'.
tasks - Displays the tasks runnable from root project 'test'.

IDE tasks
---------
cleanVisualStudio - Removes all generated Visual Studio project and solution files

Verification tasks
------------------
check - Runs all checks.

Other tasks
-----------
TestProjectDllVisualStudioFilters
TestProjectDllVisualStudioProject
TestProjectLibVisualStudioFilters
TestProjectLibVisualStudioProject

When it should be the following (output created by either changing the toolChain for VisualCpp or after installing gcc)

Build tasks
-----------
assemble - Assembles the outputs of this project. [TestProjectSharedLibrary, TestProjectStaticLibrary]
build - Assembles and tests this project. [assemble, check]
clean - Deletes the build directory.
TestProjectSharedLibrary - Assembles shared library 'testProject:sharedLibrary'.
    linkTestProjectSharedLibrary - Links shared library 'testProject:sharedLibrary'
TestProjectStaticLibrary - Assembles static library 'testProject:staticLibrary'.
    createTestProjectStaticLibrary - Creates static library 'testProject:staticLibrary'

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'test'.
components - Displays the components produced by root project 'test'. [incubating]
dependencies - Displays all dependencies declared in root project 'test'.
dependencyInsight - Displays the insight into a specific dependency in root project 'test'.
help - Displays a help message.
model - Displays the configuration model of root project 'test'. [incubating]
projects - Displays the sub-projects of root project 'test'.
properties - Displays the properties of root project 'test'.
tasks - Displays the tasks runnable from root project 'test'.

IDE tasks
---------
cleanVisualStudio - Removes all generated Visual Studio project and solution files
TestProjectVisualStudio - Generates the Visual Studio solution for native library 'TestProject'.
    TestProjectDllVisualStudio - Generates the 'TestProjectDll' Visual Studio solution file.
    TestProjectDllVisualStudioFilters
    TestProjectDllVisualStudioProject
    TestProjectDllVisualStudioSolution
    TestProjectLibVisualStudio - Generates the 'TestProjectLib' Visual Studio solution file.
    TestProjectLibVisualStudioFilters
    TestProjectLibVisualStudioProject
    TestProjectLibVisualStudioSolution

Context

Discovered while writing code to allow my Gradle scripts to intentionally select a specific toolChain. Doesn't block anything, just, confusing initially.

Steps to Reproduce (for bugs)

Code above.

Your Environment

Gradle 3.1
Windows 10 Version 1607

The idea for solving this is for us to provide an API that one can use to build a plugin repository implementation, which is effectively just a mapping table. The user is responsible for sourcing whatever data they need and building the definition. There are several possible variants on this; e.g. a callback/factory style API instead of specify everything up front.

This plugin repository would participate in resolution just like other plugin repositories.

I suspect that javaexec is leaking classloaders since 3.2-rc-1. I'm using javaexec to trigger other Gradle builds:

javaexec {
     classpath 'wrapper/gradle-wrapper.jar'
     main = 'org.gradle.wrapper.GradleWrapperMain'
     args ['-b', 'externalBuildFile.gradle', 'externalTask']
}

This externalBuildFile.gradle imports an Ant taskdef that where the impl loads native libraries. Now, when I execute this block twice, with 3.2-rc-1 I get an error the second time:

java.lang.UnsatisfiedLinkError: Native Library /full/path/to/my.so already loaded in other classloader

It works fine when running the same with Gradle 3.1.

Expected Behavior

Classloaders that are instantiated for javaexec should be closed once done.

Your Environment

Linux Mint 18

When publishing to an empty file directory using uploadArchives a warning is emitted

Could not find metadata org.gradle:solution/maven-metadata.xml in remote (file:///Users/Rene/training/labs/19-maven-uploading/solution/build/repo

on quiet log level. This should be redirected to info logging. Otherwise that confuses users.

Expected Behavior

Given log message should not show up unless using --info or --debug logging.

Current Behavior

Given log message appears by default (in "quiet" logging)

Context

This unnecessarily adds to default build output.

Related to https://issues.apache.org/jira/browse/GROOVY-7879 we seem to do something wrong when generating the proxies for the @Managed model. The test InterfaceBackedManagedTypeIntegrationTest fails on Java 9 with

java.lang.IncompatibleClassChangeError: Method Person.getName()Ljava/lang/String; must be InterfaceMethodref constant

A third-party library uses an open-ended version range to resolve a dependency (in this case, on jackson-databind).

Recently, a 2.9.0-SNAPSHOT was released for jackson-databind, which in combination with the third-party library above, made previously working builds non-repeatable, because the same build was now pulling in a -SNAPSHOT dependency to a non-binary compatible version.

I don't believe the third-party library should be defining their transitive dependencies this way (see maxmind/GeoIP2-java#77 for my discussion with them -- perhaps someone from the gradle team could weigh in with their thoughts). However, I think Gradle could do more in this type of situation to ensure build repeatability (I don't know what).

I also don't think this issue is limited to snapshots. Even if my build did not enable snapshots, as soon as jackson 2.9.0 was released, I would have run into the same issue.

The third-party lib POM is:

https://github.com/maxmind/MaxMind-DB-Reader-java/blob/master/pom.xml#L40

which pulls in Jackson-databind with a version range [2.7.0,).

(Edit: it used to, MaxMind updated it to a fixed version, though they say the change is temporary)

Expected Behavior

• Builds should be repeatable

Current Behavior

• Builds are not repeatable if a transitive dependency uses a version range that may cause different deps to be included depending on external releases

Context

• My build was working. Then a build of the same code version stopped working, with failing tests due to binary incompatibility. Upon further investigation using the dependencyAnalysis tool, it was determined that a new non-binary compatible snapshot build was being pulled in.

Steps to Reproduce (for bugs)

Here is a simple build.gradle for reproduction:

repositories {
  mavenCentral()
  maven {
    url "https://oss.sonatype.org/content/repositories/snapshots"
  }
}

apply plugin: 'java'

dependencies {
  compile("com.maxmind.geoip2:geoip2:2.8.0") {
    // workaround https://github.com/maxmind/GeoIP2-java/issues/77
    //exclude group: 'com.fasterxml.jackson.core'
  }
}

task wrapper(type: Wrapper) {
  gradleVersion = '3.1'
}

Your Environment

• Build scan URL: https://scans.gradle.com/s/jjq3xdqmhhd6i

Related to #707

For performance reasons, we should standardize how we use caches for file resources that are created on first use. For example:

• Creating the Zinc compiler - Failed build
• Generating the Gradle API JAR - Failed build

Proposed option for an implementation by @adammurdoch:

lock the cache, if initialized, create the compiler.
if not, unlock the cache, initialize it into a temporary dir, lock the cache again and copy the files in and create the compiler.

Plugin developers are currently using the internal API for convention mapping to map extension values to task properties. Convention mapping is the only effective method to avoid evaluation order issues for this use case.

We need to identify a first-class, public API solution for the problem. The software model was supposed to solve the issue. As we won't promote the software model for the JVM domain, we'll need a different solution. Part of this ticket is to identify an appropriate solution. This could be convention mapping but doesn't have to.

If we go with convention mapping then we should make the API public. We should also tweak the contract to make the value immutable when the task starts executing.

From GRADLE-3543

Some sort of generic access to create "instantiated" objects from within plugins is a common need.

When writing nested DSL objects there is no way to get the same DSL decoration that you get from calling project.extensions.create().

For instance:

class Outer {
  Inner inner = new Inner()

  Inner getInner() {
    return inner;
  }

  void inner(Action<? super Inner> configuration) {
    configuration.execute(inner)
  }
}

The Inner object will not be decoreated.

There should be a method like Project.instantiate that allows users to get decoration when they need it:

class Outer {
  Inner inner

  Outer(Project project) {
    inner = project.instantiate(Inner)
  }

  Inner getInner() {
    return inner;
  }

  void inner(Action<? super Inner> configuration) {
    configuration.execute(inner)
  }
}

For the software model, generally you should prefer using @Managed types, and let Gradle take care of decoration, instead of using the instantiator. And in fact, I think we want to move in the opposite direction and back port managed types to the current model, so that plugin authors can implement their extensions and tasks as managed types.

If we do want to make the instantiator visible in the software model, it should be made available as a service, so that a rule can then simply use it as an input.

Related to #707

The Scala plugin allows for using different versions of Zinc with the help of a custom configuration named zinc. When creating the Zinc compiler the file cache currently locks independent of the Zinc version. The goal is to lock the cache based on the provided Zinc version to avoid contention and for better separation.

From https://discuss.gradle.org/t/jigsaw-b136-gradle-problem/19580

This is with gradle 3.0 and jdk9 jigsaw b136:

https://mail-archives.apache.org/mod_mbox/groovy-dev/201609.mbox/%3CCADQzvmn_NqB843%3DTVJFvZww7KDcEgxG2Xsr5dDHWkLtq_ZMXEg%40mail.gmail.com%3E

InProcessGroovyCompilerIntegrationTest and InProcessJavaCompilerIntegrationTest which fail for Annotation Processing with java.lang.RuntimeException: Annotation Processor Classpath is contaminated by Gradle ClassLoader at com.test.SimpleAnnotationProcessor.process(SimpleAnnotationProcessor.java:22)

Current state of analysis:
When compiling Java classes on Java 9 with an embedded Java compiler (non-forking) then the Gradle classes are accessible from the Annotation Processor. This is because javac is always loaded by jdk.internal.loader.ClassLoaders$AppClassLoader since we only load javax.tools.ToolProvider via the isolatedClassloader which then loads the JavaCompiler via jdk.internal.loader.ClassLoaders$AppClassLoader. I did try to load the implemenation of JavaCompiler via isolatedClassloader but it seems to that for this to work FilteringClassloader needs to be able to provide Java 9 modules via getServicesCatalog which I do not know how to implement.
All this happens in JdkTools.

Consider you have a project like:

root/
   foo/
       sub1/build.gradle
       sub2/build.gradle
   build.gradle
   settings.gradle

This is an accepted, but strange way to include the subprojects:

include ":foo/sub1"
include ":foo/sub2"

This adds two subprojects named foo/sub1 and foo/sub2. This causes problems in Eclipse and Sonar because the slash is not allowed in project names.

This happens to work because we convert the project path + name into a file path, which happens to line up with the actual project layout.

I would expect if we fixed this, we would go through a period of deprecated warnings about what values include() accepts. We also have a parallel/similar API for composite builds that always uses file paths (includeBuild()).

We may consider unifying the includeBuild and include APIs to have something similar.

Expected Behavior

I would expect this to fail (invalid project name/path?) or "do the right thing" by converting the slashes into colon path separators.

Current Behavior

Silent, mostly works.

Context

I've seen this come up from time to time since it seems normal to use the file path vs the project path.

Steps to Reproduce (for bugs)

This happens always.

Your Environment

This happens everywhere.

From https://discuss.gradle.org/t/urlclassloader-classcastexception/19579

Using ca9d78a72a1e76e9 from the JDK9 repository I get the following exception when trying to start gradle 3.0 on our CI server:

Since that part of the code is basically unchanged for a long time and since the ClassCastException problem was already "solved" in gradle I can only assume, that something supposed to recognize JDK9 is not working for this snapshot build.