Ryan Schmitt
11/30/2023, 1:57 AMextendsFrom
a non-detached configuration? It's certainly not behaving the way I would expectRyan Schmitt
11/30/2023, 4:33 PM<dependencyManagement>
sections of dependencies' POM files, or does it just ignore them?Gabriel Feo
12/04/2023, 7:17 PMtestCompileOnly
. Why does this make sense? I thought JUnit 4 org.junit.Assert
for example would need to be present in the test runtime classpath as well
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter:5.7.1'
testCompileOnly 'junit:junit:4.13'
testRuntimeOnly 'org.junit.vintage:junit-vintage-engine'
testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}
Ivan CLOVIS Canet
12/11/2023, 7:32 PM./gradlew :dependencies
does display the configuration and its dependencies, as I expected.
Now, I would like to create a Sync
task that takes the ZIP file from dependencies and puts it somewhere else. How can I create a task that takes dependency resolution artifacts as input?Ivan CLOVIS Canet
12/11/2023, 8:07 PMval getAllFiles by tasks.registering(Copy::class) {
from(configurations.foo)
into(layout.buildDirectory.dir("foo"))
}
However all the files are copied directly into that directory. The files are ZIPs, and I would like to extract all of them into a single directory, keeping the same structure.
For example, if I have a ZIP file a.zip
which contains:
a.txt
b.txt
and a ZIP file b.zip
which contains:
bar/z.txt
I would like to generate the output:
build/
extracted/
a/
a.txt
b.txt
b/
bar/
z.txt
According to StackOverflow, the way to extract files is to use zipTree
, so I tried:
val organizeTransitiveJsResources by tasks.registering(Sync::class) {
val zips = provider {
getAllFiles.get().outputs.files.asFileTree
.map { zipTree(it) }
}
from(zips)
into(layout.buildDirectory.dir("kjs-transitive-assets-extracted"))
}
But the file structure isn't kept. Also, it only works if :getAllFiles
has been called once before, since the file tree is evaluated before the execution of the dependencies.
How can I unzip all the files from the configuration into a single directory, keeping the structure?Theodore Gonzalez
12/13/2023, 4:22 AMVampire
12/13/2023, 4:50 PMplugins { `jvm-ecosystem` }
val a by configurations.creating { attributes { attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(LibraryElements::class.java, LibraryElements.CLASSES)) } }
repositories { gradlePluginPortal() }
dependencies { a("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.10") }
a.incoming.files.files.forEach(::println)
Or more importantly, how to work-around it, which attributes to set or similar so that it becomes resolvable.tony
12/14/2023, 4:01 AMplugins {
id "java-platform"
}
javaPlatform {
allowDependencies()
}
dependencies {
attributesSchema { schema ->
schema.attribute(Role.ROLE_ATTRIBUTE) { matchingStrategy ->
matchingStrategy.compatibilityRules.add(myRule)
}
}
}
I am not seeing "myRule"s execute()
method being called. I am also setting attributes on my configurations. This works fine for other module types (libraries, applications)Ben Madore
12/18/2023, 8:49 PMBOM
as a platform for easy dependency management e.g. in the library we have:
implementation(platform("org.springframework.boot:spring-boot-dependencies:3.1.5"))
The problem is that the consumer of the library is now getting a build failure because spring-boot-dependencies:3.1.5
requires a version of graphql-java
(20.2) that doesn’t match what the consuming project needs - which comes from com.netflix.graphql.dgs:graphql-dgs-spring-boot-starter:5.5.3
-> com.graphql-java:graphql-java:{strictly [19.5, 20[; prefer 19.5; reject 18.2}'
.
(Note, the library itself doesn’t use graphql-java
at all )
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':bootJarMainClassName'.
> Could not resolve all files for configuration ':productionRuntimeClasspath'.
> Could not resolve com.graphql-java:graphql-java:19.6.
Required by:
project :
> Cannot find a version of 'com.graphql-java:graphql-java' that satisfies the version constraints:
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs.codegen:graphql-dgs-codegen-shared-core:5.12.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.2'
Constraint path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.graphql-java:graphql-java:19.6'
Constraint path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:{prefer 18.3}'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.foobar.atlas:atlas-graphql-client:20230531.1658' (runtime) --> 'com.netflix.graphql.dgs:graphql-dgs-client:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.5'
Constraint path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-spring-boot-starter:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs-platform:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:{strictly [19.5, 20[; prefer 19.5; reject 18.2}'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-spring-boot-starter:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-error-types:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.5'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-extended-scalars:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java-extended-scalars:19.1' (runtimeElements) --> 'com.graphql-java:graphql-java:19.2'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-extended-scalars:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.5'
Constraint path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'org.springframework.boot:spring-boot-dependencies:3.1.5' (platform-runtime) --> 'com.graphql-java:graphql-java:20.2'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.foobar.atlas:atlas-graphql-client:20230531.1658' (runtime) --> 'com.netflix.graphql.dgs:graphql-dgs-client:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs-subscription-types:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.5'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-extended-scalars:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs:5.5.3' (runtimeElements) --> 'com.apollographql.federation:federation-graphql-java-support:2.1.0' (runtimeElements) --> 'com.graphql-java:graphql-java:19.2'
Dependency path 'com.foobar.baz.graph:baz-graph:auto-version-on-ci' --> 'com.netflix.graphql.dgs:graphql-dgs-extended-scalars:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs:5.5.3' (runtimeElements) --> 'com.netflix.graphql.dgs:graphql-dgs-mocking:5.5.3' (runtimeElements) --> 'com.graphql-java:graphql-java:19.5'
Interestingly spring-boot-dependencies:3.1.5
doesn’t show up anywhere when running ./gradlew dependencyInsight --dependency "com.graphql-java:graphql-java"
Is there a best-practice for applying platforms such that they aren’t exposed transitively?
it seems odd to me that spring-boot-dependencies
doesn’t show up in either ./gradlew dependencies
or dependencyInsight
but still can cause the build to failRonanb Browne
12/19/2023, 11:58 AMChris Doré
12/19/2023, 11:51 PMtwisterrob
01/07/2024, 7:34 PMthadhouse
01/07/2024, 11:27 PMMartin
01/08/2024, 1:40 PMg:a:1
and g:b:2
. I could create 2 different non-transitive configurations but that feels a bit overkill. Is there anything lower level than Configuration
?Kuba Petržílka
01/19/2024, 8:06 PMkubapet@localhost ~/P/dossier-profile-gradle (improvement/PF-21178-fixing-critical-vulnerabilities) [1]> ./gradlew installDist
> Task :dfr-frontend-tapestry5:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':dfr-frontend-tapestry5:compileJava'.
> Could not resolve all files for configuration ':dfr-frontend-tapestry5:compileClasspath'.
> Could not find tapestry-core-5.8.3-jakarta.jar (org.apache.tapestry:tapestry-core:5.8.3).
Searched in the following locations:
https://****CENSORED****/nexus/repository/maven-public/org/apache/tapestry/tapestry-core/5.8.3/tapestry-core-5.8.3-jakarta.jar
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at <https://help.gradle.org>.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to <https://docs.gradle.org/8.5/userguide/command_line_interface.html#sec:command_line_warnings> in the Gradle documentation.
BUILD FAILED in 3s
177 actionable tasks: 65 executed, 112 up-to-date
The tapestry-core-5.8.3-jakarta.jar
is our vendored version of tapestry-core-5.8.3.jar
transformed with eclipse transformer to be compliant with jakarta EE
The artifact is uploaded on our nexus server and it is actually there. When I ctrl+click the link or run wget and the exact same URL (https://****CENSORED****/nexus/repository/maven-public/org/apache/tapestry/tapestry-core/5.8.3/tapestry-core-5.8.3-jakarta.jar)
it just works.. I cannot wrap my head around it. --debug or --stacktrace doesn't really give me some more usefuly info. Why it claims it cannot find it while the jar artifact is just there on that particular URL?Vampire
01/22/2024, 11:15 AMCacheableRule
in the docs is very sparse.
Can someone provide more insight on it?
• when would you use it?
• when would you not use it?
• what exactly is cached there, unless you use a RepositoryResourceAccessor
or do other significant work, it is just setting some configuration, isn't it. Is it really worth to cache in that case or is the overhead bigger than the potential saving? The examples in the docs are all cacheable and also all the rules in gradlex-org/java-ecosystem-capabilities that @Jendrik Johannes created are defined cacheable and the docs even recommend to put rules in standalone classes for the sole purpose of defining them cacheable.Vampire
01/22/2024, 11:46 PMAttribute.of("my.custom.attribute", Boolean::class.java)
and then try to set it, I get "Expected boolean but was:java.lang.Boolean"Vampire
01/23/2024, 8:50 AMVampire
01/24/2024, 11:12 AMNamed
for attributes like public interface Usage extends Named
?
I mean opposed to just having the attributes with type String
.
In the module metadata they are just strings.
To set them you use the String
constants in the interface.
You can also use any arbitrary other string.
So the only effect I can realize right now is, that it is more cumbersome to set the attributes by needing to use objects.named
to create the value instead of just setting a String
as value.Vampire
01/24/2024, 11:43 AMOPERATING_SYSTEM_ATTRIBUTE
and those having a value for the attribute.
I thought maybe componentFilter
in an ArtifactView
would allow to do that, but it only allows to match on the ComponentIdentifier
. 😕Oleg Nenashev
02/11/2024, 7:14 PMvierbergenlars
02/16/2024, 9:07 AMorg.gradle.jvm.version
attribute set on the outgoing variant so both jars are published and Gradle automatically selects the correct jar in a consuming project. I found this page https://docs.gradle.org/current/userguide/publishing_customization.html, but that doesn't seem to describe the part how I put the correct attribute on the outgoing configuration, and how to associate the output of the Java 17 task with that configuration?Zak Taccardi
02/26/2024, 10:15 PMorg.jetbrains.kotlinx:kotlinx-coroutines-*
)
◦ then include the BOM as a dependency to that configuration as well
is this possible?tony
02/28/2024, 12:47 AM// settings.gradle.kts
gradle.afterProject { p ->
p.dependencies.add("api", platform(project(":platform")))
}
or would I want beforeProject
or even allprojects
?StefMa
02/29/2024, 3:21 PM- Variant 'runtimeElements' capability org.pkl-lang:pkl-codegen-java:0.26.0-SNAPSHOT declares a runtime of a library, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally:
- Incompatible because this component declares a component compatible with Java 17 and the consumer needed a component compatible with Java 11
Can someone help me to understand this 🙈
I don't get it fully.. What is only compatible with Java 11?
And who declares a component that is compatible with Java 17?melix
03/08/2024, 3:49 PMCaleb Cushing
03/19/2024, 1:34 AMerrorprone
scope from my locks, unlocking the dependency. I can't figure out why it's different (correct) locally only. That's kind of good though, if I have the only environment that produces the correct result... then everyone else can reproduce the incorrect one.
I thought I had it figured out, but my automated build still cleans it. This is the last PR where it did it
https://github.com/xenoterracide/spring-app-commons/pull/11
and the job that creates those PR's
https://github.com/xenoterracide/spring-app-commons/blob/main/.github/workflows/update-java.yml
I have verified that errorprone is running in CI (by causing it to fail). No I don't have any init scripts locally, I had vampire test this locally too. I thought I had it. That it was related to using buildScript { depenendencyLocking.lockAllConfigurations() }
instead of buildScript { dependencyLocking { lockAllConfigurations() }}
but I guess that wasn't it.
That build does produce a build scan
https://github.com/xenoterracide/spring-app-commons/actions/runs/8274833680tony
03/19/2024, 5:35 PMguice-4.2.2-no_aop.jar
as a transitive dependency. (com.google.inject:guice:4.2.2
)
I have a java-platform that constrains guice to 6.0.0. These two requirements combined have gradle looking for guice-6.0.0-no_aop.jar
, which doesn't exist. What's the simplest way to tell gradle to drop the no_aop
classifier when trying to resolve guice?Dylan Bolger
03/19/2024, 7:45 PMmavenLocal()
over a RELEASE one living in a Maven Repository? I'd like it where if the artifact exists in mavenLocal, it's preferred and used. Otherwise if a RELEASE version is found, it can be used.
I think this goes against Gradle's typical rules of preferring the highest version first (1.0-RELEASE > 1.0-SNAPSHOT). We have our architecture set up in such a way that doing composite builds isn't practical and we'd like to keep referring to mavenLocal, despite it's pitfalls.
I've seen examples where you can prefer a local dependency on a project(':myProject')
over a artifact coming from elsewhere, but I'm unsure how to take on this approach if the project I'd like to refer to doesn't live in the same code repository/Gradle project space.John
03/22/2024, 2:06 PM