eric
04/30/2022, 3:05 PMChris Lee
04/30/2022, 4:10 PMeric
04/30/2022, 4:12 PMChris Lee
04/30/2022, 4:15 PMdependencyResolutionManagement {
versionCatalogs {
create("libs") {
val xVer = "1.1.4"
version("xVer", xVer)
library("xLib", "org.x", "lib").versionRef("xVer")
library("yLib", "org.y:lib:y.${xVer}")
}
}
}
Chris Lee
04/30/2022, 4:16 PMfrom
in the API to read a TOML file, allowing to use both where appropriate. Personally I prefer the type-safety, expressiveness and flexibility of the API.grossws
04/30/2022, 4:19 PMeric
04/30/2022, 4:34 PMeric
05/01/2022, 4:40 AMversionCatalogs {
create("libs") {
library("libraryX", "com.dep:libraryx:1.6." + readExistingVersion("libraryY"))
}
}
but i’m not seeing any read apis availablegrossws
05/01/2022, 5:12 AMVersionCatalogExtension
on projectsgrossws
05/01/2022, 5:12 AMgrossws
05/01/2022, 5:17 AMsettings.gradle[.kts]
(or relevant project if you publish catalog later)eric
05/01/2022, 5:18 AMeric
05/01/2022, 5:19 AMresolutionStrategy
to force resolution of combined versionseric
05/01/2022, 5:20 AMgrossws
05/01/2022, 5:28 AMdependencyResolutionManagement { versionCatalogs { create("libs") { version("some-alias", "x.y.z"); version ("another-alias", "w.x.y.z") } } }
alongside autoimport from libs.versions.toml
and then add another subproject with java-platform
plugin and adding relevant dependencies like dependencies { constaints { api(libs.fisrt.dep) ; api(libs.second.dep) } }
grossws
05/01/2022, 5:30 AMeric
05/01/2022, 5:30 AMeric
05/01/2022, 5:30 AMgrossws
05/01/2022, 5:31 AMVampire
05/01/2022, 11:51 AMeric
05/01/2022, 1:50 PMephemient
05/01/2022, 11:58 PMeric
05/02/2022, 12:03 AMgrossws
05/02/2022, 5:23 AMgrossws
05/02/2022, 5:25 AMephemient
05/02/2022, 8:23 PMjavaPlatform {
allowDependencies()
}
so that they can be added as normally dependencies and not constraints, as you should be able to find in the documentationephemient
05/02/2022, 8:25 PMgrossws
05/02/2022, 8:44 PMjavaPlatform.allowDependencies()
. And the same bom in dependencies and constraints have different semantics. dependencies { api(platform(libs.jackson.bom)) }
will effectively add constraints from it to your platform and dependencies { constraints { api(platform(libs.jackson.bom)) } }
will constraint bom itself but wouldn't add its contents to constraints.
In case of publishing pom would have something like
<dependencyManagement>
<dependencies>
<dependency>
<groupId>your.group.id</groupId>
<artifactId>artifact.id</artifactId>
<scope>compile</scope>
</dependency>
</dependencies>
</dependencyManagement>
which does seem wrong tbh. IIRC maven doesn't like unversioned deps in dependencyManagement
section though I couldn't point where I read that.