gradle / gradle Goto Github PK
View Code? Open in Web Editor NEWAdaptable, fast automation for all
Home Page: https://gradle.org
License: Apache License 2.0
Adaptable, fast automation for all
Home Page: https://gradle.org
License: Apache License 2.0
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:
Stack trace
[22:28:49][Step 2/3] Starting a Gradle Daemon, 2 busy and 1 incompatible Daemons could not be reused, use --status for details
[22:28:51][Step 2/3] :buildSrc:clean UP-TO-DATE[22:28:51][Step 2/3] :buildSrc:compileJava UP-TO-DATE
[22:28:52][Step 2/3] :buildSrc:compileGroovy[22:28:52][Step 2/3] Error occurred during initialization of VM[22:28:52]
[Step 2/3] java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: java.base)
[22:28:52][Step 2/3] at worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager.checkPermission(BootstrapSecurityManager.java:60)
[22:28:52][Step 2/3] at java.lang.SecurityManager.checkPropertyAccess(java.base@9-internal/SecurityManager.java:1292)
[22:28:52][Step 2/3] at java.lang.System.getProperty(java.base@9-internal/System.java:761)
[22:28:52][Step 2/3] at java.lang.ClassLoader.initSystemClassLoader(java.base@9-internal/ClassLoader.java:1709)
[22:28:52][Step 2/3] at java.lang.System.initPhase3(java.base@9-internal/System.java:1979)
[22:28:52][Step 2/3]
[22:28:52][Step 2/3] :buildSrc:compileGroovy FAILED
[22:28:52][Step 2/3] :buildSrc:processResources UP-TO-DATE
[22:28:52][Step 2/3] :buildSrc:processTestResources UP-TO-DATE
[22:28:52][Step 2/3]
[22:28:52][Step 2/3]
[22:28:52][Step 2/3] BUILD FAILED
[22:28:52][Step 2/3]
[22:28:52][Step 2/3] Total time: 3.723 secs
[22:28:52][Step 2/3] ##teamcity[buildProblem identity='1909892886' description='Execution failed for task |':compileGroovy|'. org.gradle.process.internal.worker.WorkerProcessException: Failed to run Gradle Compiler Daemon' type='gradleBuildProblem']
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.
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.
apply plugin: 'project-report'
in build.gradle
then run dependencyReport
This just prints BUILD SUCCESSFUL
without any URL to the actual report.
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
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.
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.
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.
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.
See also the full checklist.
Daemons running leaky code can accumulate open file descriptors and fail at some point with some Too many open files
error.
Like daemons are expired according to memory/gc pressure, they should be expired when they keep a too large number of open file descriptors.
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.
Currently we track 1.8
, i.e. major and minor version for JavaCompile
.
We should also track
GroovyCompile
here:
Many users would like to send their own messages to the progress logger. Also see elastic/elasticsearch#18935
Related to #707
For performance reasons, we should standardize how we use caches for file resources that are created on first use. For example:
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.
I thought we had already done this at some point.
We already have project.copy
, we should provide the Sync-equivalent.
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).
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
.
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.
When using the Announce plugin on Mac OS we should use system notifications.
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.
Run ./gradlew build
on Mac OS. Then BuildAnnouncementsPluginIntegrationTest
will fail.
Using system notification via Apple script seem to be easy. We only would need to change AppleScriptBackedGrowlAnnouncer.
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.
All durations calculations (e.g. those for build times) should never produce a negative value.
We sometimes encounter negative durations during builds that negatively affects logic and produces inaccurate logs.
This causes sporadic failures on Gradle CI, at the very least.
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
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
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/
Local host look-up should be speedy, or if not, cached.
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
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.
This happens always.
macOS Sierra
Given the following script:
task a {
finalizedBy 'b'
}
task b {
finalizedBy 'b'
}
Invoking the ./gradlew a
should detect a cycle.
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)
...
Tested on Gradle 3.2-rc-1, not a regression as the code fail all the way back to Gradle 1.12.
./gradlew a
with the provided sample.
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.
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.
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
Buildling with VS toolchain should work when VS15 is instaled
doesn't find stdio.h (or something like that)
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.
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.
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.
I would expect this to fail (invalid project name/path?) or "do the right thing" by converting the slashes into colon path separators.
Silent, mostly works.
I've seen this come up from time to time since it seems normal to use the file path vs the project path.
This happens always.
This happens everywhere.
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.
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.
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.
Delete the plugin code under jetty
subproject and anything in the Gradle core infrastructure that uses it.
Users will have to use the external Gretty plugin.
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.
All environments.
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
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
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
I am trying to produce binaries for VS2015 with specific base name
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'
}
}
Z:\git\gradle>gradlew --version
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
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.
Given log message should not show up unless using --info
or --debug
logging.
Given log message appears by default (in "quiet" logging)
This unnecessarily adds to default build output.
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"
--offline
modeGradle 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)
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
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.
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.
When such a task is run as a dependency of the classes task, changes under src/main/webapp do not retrigger the build.
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.
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.
This forum post expose a common scenario that is well documented in Gradle documentation.
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.
The friction level for new developers is higher than it should be.
N/A
See forum post: https://discuss.gradle.org/t/how-to-make-gradle-choose-a-different-version-of-c-compiler/20181
@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.
From https://discuss.gradle.org/t/jigsaw-b136-gradle-problem/19580
This is with gradle 3.0 and jdk9 jigsaw b136:
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")
}
}
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)
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'
}
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
https://code-review.gradle.org/cru/REVIEW-6309
See also the full checklist.
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
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.
Classloaders that are instantiated for javaexec
should be closed once done.
Linux Mint 18
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.
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
.
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.
The visual-studio plugin should either always generate all tasks, regardless of the available toolchains, or report a useful error.
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
Discovered while writing code to allow my Gradle scripts to intentionally select a specific toolChain. Doesn't block anything, just, confusing initially.
Code above.
Gradle 3.1
Windows 10 Version 1607
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.