Javi
11/18/2022, 9:24 AMPhanindra R
11/21/2022, 9:41 PMapi importedCatalog.someThirdPartyLibrary
brings in an older version of org.apache.httpcomponents:httpclient
. In this case someThirdPartyLibrary
works just fine with a newer httpclient
with security patches. It'd be nice to have some control over important transitive dependency versions. Here's a few ways to ensure that with respective pros & cons.
Solution 1) Create a Version Catalog and a Platform/BOM from the same source, e.g. Micronaut toml and bom
a. Import the Catalog and use that for dependencies.
b. Also apply the bom/platform for the constraints.
Pros: Works
Cons:
• Versions come in hardcoded in the bom/platform so cannot use the native version overriding feature in Version Catalog anymore, e.g. version('alias', 'version') // in settings.gradle
• Can be done but there's no native support for publishing a catalog and a platform from the same source.
Solution 2) Make sure all important libraries with preferred versions are listed in in the catalog and do the below
dependencies{
api importedCatalog.someLibrary1
api importedCatalog.someLibrary2
// more..
constraints{
project.extensions.findByType(VersionCatalogsExtension).find('importedCatalog').get().libraryAliases.each {libraryAlias ->
api versionCatalog.findLibrary(libraryAlias).get()
}
importedCatalog.bundles.reallyImportantLibraries.get().each { library ->
api("${library}!!") // avoid unintended upgrades
}
}
}
Pros: Works
Cons: Too clumsy to repeat in all repositories.
Solution 3) To be Supported
dependencies{
api importedCatalog.someLibrary1
api importedCatalog.someLibrary2
// more..
constraints{
api importedCatalog // or preferably "api importedCatalog.libraries.filter{..}" // all [libraries] entries will be used . We could also go for a potentially autogenerated bundle: importedCatalog.bundles._allLibraries
api importedCatalog.bundles.reallyImportantLibraries {strictly true} // all entries from the bundle will be applied with a strictly constraint. This is for avoiding unintended upgrades.
}
}
Pros: All will come from the catalog. No need for a complementing platform artifact. The version overriding in the settings.gradle will continue to work even for the transitive libraries due to the constraints.
Cons: No support exists yet.
--------------------------------------------
Solutions (1) and (2) work fine in the context of a single repo but the Solution (3) could be efficient and more convenient at scale.
My question - Is Solution (3) something Gradle would be interested in exploring or is there a way to do this already?Igor Wojda
11/22/2022, 12:14 PMandroidx-compose-ui-tooling-preview = { module = "androidx.compose.ui:ui-tooling-preview" }
in the libs.versions.toml
file - how library version is determined without version.ref
attribute?Gabriel Feo
11/23/2022, 3:59 PMdependencyResolutionManagement
isn't enough for included builds. Do I need to define repositories in both dependencyResolutionManagement
and pluginManagement
?
Could not resolve all files for configuration 'classpath'.
> Could not find com.android.tools.build:gradle:7.3.1.
Searched in the following locations:
- <https://plugins.gradle.org/m2/com/android/tools/build/gradle/7.3.1/gradle-7.3.1.pom>
If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
Required by:
unspecified:unspecified:unspecified > project :settings-plugin-included-build
Joffrey Bion
11/30/2022, 3:28 PMGabriel Feo
11/30/2022, 7:18 PMimplementation
, even when part of the public API. In that case, the consumer will also add each dependency required to compile as implementation
. Is there any harm in doing this? Always saw it as only a nuisance, but now I suspect some "caching issues" we're seeing might be caused by this, e,g, failures for unresolved reference, then success after developer nukes Gradle home (yep 👀), as if something should've been recompiled and wasn'tPhanindra R
12/05/2022, 11:35 PM// error
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':my-project'.
> Could not resolve all dependencies for configuration ':my-project:compileClasspath'.
> Cannot convert the provided notation to an object of type DependencyConstraint: [org.apache.commons:commons-math3:3.5].
The following types/formats are supported:
- Instances of DependencyConstraint.
- String or CharSequence values, for example 'org.gradle:gradle-core:1.0'.
- Maps, for example [group: 'org.gradle', name: 'gradle-core', version: '1.0'].
- Projects, for example project(':some:project:path').
- Instances of ProjectDependency.
Comprehensive documentation on dependency notations is available in DSL reference for DependencyHandler type.
Here's what's causing the error
// build.gradle
dependencies{api SomeClassFromBuildSrc.testBundle()} // the Provider<bundle> here is constructed programmatically..
//
static public Provider<ExternalModuleDependencyBundle> testBundle() {
return new DefaultProvider(new SomeCallable());
}
//
@CompileStatic
class ExternalModuleDependencyBundleImpl extends ArrayList<MinimalExternalModuleDependency> implements ExternalModuleDependencyBundle {
}
//
@CompileStatic
class SomeCallable implements Callable<ExternalModuleDependencyBundle> {
@Override
ExternalModuleDependencyBundle call() throws Exception {
ExternalModuleDependencyBundleImpl bundle = new ExternalModuleDependencyBundleImpl()
ModuleIdentifier module = DefaultModuleIdentifier.newId('org.apache.commons', 'commons-math3')
VersionConstraint versionConstraint = new DefaultMutableVersionConstraint('3.5')
DefaultMinimalDependency dependency = new DefaultMinimalDependency(module, versionConstraint)
bundle.add(dependency)
return bundle
}
}
I noticed that the bundles from a real catalog might be relying on internal Provider and ValueSource classes. Is there a way to make it work? Above is a simplified example but what I'm trying to do is something like this
api SomeClassFromBuildSrc.transform(libs.bundles.bundle1) // transform is supposed to modify the contents in the bundle like applying a 'strictly' to each element in the bundle
Ryan Schmitt
12/06/2022, 1:45 AMme.champeau.gradle.japicmp
plugin. The idea is to compare the jar file produced by the current build to an older, baseline jar file in order to check for breaking changes in the API. What I'd like to do is fetch the most recent published version of my project and supply its jar file as the oldClasspath
, and then supply tasks.findByName("jar")
as the newClasspath
that will be checked for breaking changes.
The problem I'm facing is that whenever I declare a dependency on an older version of my project, it gets subjected to dependency substitution, after the manner of a composite build:
apiBaseline
\--- com.mygroup:my-project:{strictly 1.1.19} -> project : (*)
This even happens with a detachedConfiguration
, so I'm not sure what else to try. Can someone suggest a way around this? As far as I know, I only need the jar file for my-project
, not an entire classpath as produced by full dependency resolution, so I may be able to work with a lower-level API than ConfigurationContainer
if one exists.TrevJonez
12/13/2022, 10:26 PMb.g.kts
plugins {
alias(libs.plugins.foo).apply(false)
}
jschneider
12/15/2022, 2:06 PMFritjof Höst
01/02/2023, 1:21 PMCannot resolve symbol 'MyClass'
Add dependency on module 'tooling.installation.module'
In the build.gradle
I have implementation 'tooling:installation'
, and in the settings.gradle
I have:
includeBuild('tooling') {
dependencySubstitution {
substitute module('tooling:installation') using project(':installation')
Everything compiles, and runs as expected, it’s simply that whenever I uses the classes within the substituted packages everything is red.Brian Stewart
01/10/2023, 6:37 PMannotationProcessor
dependency if there are other annotationProcessor
dependencies declared already.Fritjof Höst
02/02/2023, 10:07 AMInvalid catalog definition:
- Problem: In version catalog libs, you can only call the 'from' method a single time.
Reason: The method was called more than once.
Possible solution: Remove further usages of the method call.
Please refer to <https://docs.gradle.org/7.6/userguide/version_catalog_problems.html#too_many_import_invocation> for more details about this problem.
I only have one usage of it as far as I can tell.
dependencyResolutionManagement {
versionCatalogs {
libs {
from(files("gradle/libs.versions.toml"))
}
}
}
I can’t find anything relevant when running with either --stacktrace
, --info
or --debug
. So I have no idea where this is coming from. The only thing I suspect is that we use an included build that point toward the same .toml
-file, but since that is in a separate build it shouldn’t interfere, right?
Any idea on how to find my “second” usage of from()
?Fritjof Höst
02/02/2023, 1:23 PMYou call a task in an included build using a fully qualified path, for example :included-build-name:project-name:taskName
. Is that only valid for the CLI?
I can call :tooling:test
which works, but I can’t get it working using a dependsOn in my build file (test.dependsOn(":tooling:test")
) and then simply calling gradle test
.
So while I have a workaround in calling gradle test :tooling:test
, it would be nice to only have to call test.dummysiddhes mail
02/12/2023, 11:19 AMCristianGM
02/17/2023, 10:52 PMLeon Linhart
02/20/2023, 11:20 AMlibrary
and sandbox
. sandbox
includes library
to substitute some implementation dependencies of sandbox
. Similarly, library
includes sandbox
to substitute a testImplementation dependency. I'm using a composite build for this because I need to work on sandbox
with a different IDE instance. In theory, I think this setup should work but I'm running into issues where the dependencies are not substituted correctly. If this is something that should work, I'll write up an issue with an MCVE.Tapchicoma
02/21/2023, 2:00 PMresolutionStrategy.force
rule on transitive dependencies resolution. Is there a way to make resolutionStrategy
rule be considered as main?Ryan Schmitt
02/21/2023, 6:52 PMresolutionStrategy
?CristianGM
02/22/2023, 10:19 AMLeon Linhart
02/26/2023, 12:02 PMCristianGM
03/01/2023, 1:34 PMattributesSchema
Is it expected that dependency variants without the attribute set are resolved?
If I set any value to the producer configuration then it worksCristianGM
03/02/2023, 9:43 PMMartin
03/05/2023, 8:12 PMProblem: In version catalog libs, on alias 'material-icons-extended' notation 'androidx.compose.material:material-icons-extended' is not a valid dependency notation.
I have to wrap it in an object instead:
# Not working
compose-icons = "androidx.compose.material:material-icons-extended"
# Working
compose-icons = { module = "androidx.compose.material:material-icons-extended" }
Could both notations be allowed (since it's working fine in build scripts?) or is there something more fundamental to not allowing #1?snowe
03/10/2023, 11:10 PMfor
loop for bundles? I can only see like one benefit, but numerous downsides:
# Pros
• sharable between subprojects???
# Cons
• your versions are now hidden away in a subdirectory
• changing versions is much more complicated
• adding a dependency means you might miss adding it to a bundle
• multiple ways to configure catalogs
• versions catalog isn’t actually the source of truth
• command clicking (or jump to) for each dependency actually just jumps to generated code rather than the actual version.
I’m clearly missing something here. I only see one upside and tons of downsides. What is it that I’m missing?twisterrob
03/16/2023, 2:10 PMtwisterrob
03/17/2023, 11:56 AMandroidx.foo:foo:1.0
there's an androidx.foo:foo-ktx:1.0
dependency too (exact same version). Regardless of which dependency catalog solution we use, that's two dependencies per each androidx lib and boy there are many. I would like to simplify using Version Catalogs by never adding a -ktx
variant into the .toml
file.
I came up with
implmenentation(libs.androidx.foo.ktx)
val Provider<MinimalExternalModuleDependency>.ktx: Provider<MinimalExternalModuleDependency>
get() = this.map { it.ktx }
val MinimalExternalModuleDependency.ktx: MinimalExternalModuleDependency
get() = DefaultMinimalDependency(
DefaultModuleIdentifier.newId(this.module.group, "${this.module.name}-ktx"),
DefaultMutableVersionConstraint(this.versionConstraint)
)
but it uses only internal APIs, is there a way to re-create a dependency using Gradle DSL?gmazzo
03/20/2023, 2:45 PMrefreshing dependencies only has an impact if you actually use dynamic dependencies or that you have changing dependenciesFrom the documentation, Gradle will only try to refresh (make a
HEAD
request) dynamic (+
, SNAPTSHOT
) or changing dependencies, but no release/final/immutables ones, correct?
So why if you I do ./gradlew --refresh-dependencies
I got requests for pretty much all of them? Is there any way to avoid re-querying release/immutable artifacts?
https://scans.gradle.com/s/rl5xgme5plmce/performance/network-activity
(the scan is just a dummy project created with gradle init
plugin)kirill
03/23/2023, 1:34 AM:foo
and :bar
modules that do not depend on each other in my project. When I run :foo:someTask
, I see :bar
get configured. Is there a way to 1) not configure :bar
in that case; and/or 2) see why it gets configured?Eug
03/23/2023, 9:04 AMEug
03/23/2023, 9:04 AMThomas Broyer
03/23/2023, 11:14 AMMETA-INF/gradle-plugins/
https://docs.gradle.org/current/userguide/custom_plugins.html#example_wiring_for_a_custom_plugin