Ian Brandt
05/22/2024, 6:36 PMSteve Ebersole
05/30/2024, 3:00 PM@OutputDirectory
. This task performs XJC generation of JAXB binding classes (the java files) into said directory. Between branches we changed the package in which these classes are generated. What we've noticed is that when switching branches the output from the "other" branch is not removed and we end up with compile errors. Annoying but understandable.
However, what I don't understand is that even clean
does not help the situation. The only thing that works is clean
+ --no-build-cache
. Any thoughts on why that is?
Would switching to @OutputFiles
help with that in any way? The difference (to me anyway) is not immediately obvious from their JavadocsSteve Ebersole
05/31/2024, 2:51 PMA problem was found with the configuration of task ':sourcesJar' (type 'Jar').
- Gradle detected a problem with the following location: '/tmp/junit16008784648879827421/build/generated/sources/xjc/main/simple'.
Reason: Task ':sourcesJar' uses this output of task ':xjcSimple' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
Possible solutions:
1. Declare task ':xjcSimple' as an input of ':sourcesJar'.
2. Declare an explicit dependency on ':xjcSimple' from ':sourcesJar' using Task#dependsOn.
3. Declare an explicit dependency on ':xjcSimple' from ':sourcesJar' using Task#mustRunAfter.
Please refer to <https://docs.gradle.org/8.0/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
I add this generation task (itself) as a path in the main source-set's java sources:
final SourceSetContainer sourceSets = project.getExtensions().getByType( SourceSetContainer.class );
final SourceSet mainSourceSet = sourceSets.getByName( MAIN_SOURCE_SET_NAME );
mainSourceSet.getJava().srcDir( task );
What's super strange is that executing gradlew sourcesJar
works perfectly fine. I only see this error when calling gradlew publishToMavneLocal
(have not tried remote publishing yet)Darryl Miles
06/04/2024, 4:26 PMPiotr Minkina
06/05/2024, 11:02 AMKelvin Chung
06/06/2024, 7:54 PMProvider<List<String>>
to Sequence<String>
or a FileCollection
to a Sequence<File>
? Or am I off-base in terms of the lazy semantics contained therein?James
06/11/2024, 7:18 PMsettings.gradle.kts
file they need to add the internal maven repository, which is fine, but I would like my consumers not to be required to add gradlePluginPortal()
and mavenCentralMirror()
(link to custom maven central mirror).
My initial thought is to create a far jar that contains all the dependencies the Gradle plugin needs, but I'm unsure how to make the java-gradle-plugin
and the com.gradle.plugin-publish
plugins use the fat jar and not the normal jar? Any ideas?
edit: build.gradle.kts
file in 🧵Felix de Souza
06/12/2024, 2:43 PMRegularFile
object within a Settings
object? I’m writing a settings plugin and I was hoping to use the configuration cache friendly providers i.e. ProviderFactory#fileContents
. These take in a RegularFile
or a Provider<RegularFile>
, and I can’t seem to find a way to get an instance of one of those within the Settings
context. I resorted to just calling ProviderFactory#of
and passing in the ValueSourceProvider
that fileContents
used, and then passed the file in that way as the parameter is just a FileSystemProperty
.
That said, I’m not actually sure whether the configuration cache works at the Settings
level, but I’ve been trying to have good Provider
hygiene where possible to ease our configuration cache slog of a migration.Felix de Souza
06/12/2024, 5:34 PMDomainObjectSet
into a SetProperty
? is the recommendation to just do setProperty.value(project.provider(() -> domainObjectSet))
? I effectively want the contents of the DomainObjectSet
to be an input in a task. Property<DomainObjectSet>
doesn’t feel right and SetProperty<…>
is probably the closest. In all cases, none of these options feel that ergonomic.Martin
06/18/2024, 8:00 AMLennart Jörelid
06/18/2024, 2:41 PMELIEZER HUACCAYCACHACC CAJAMARCA
06/22/2024, 8:44 PMAustin C
06/24/2024, 4:43 AMChristoph Sturm
06/25/2024, 10:40 AMChristoph Sturm
06/25/2024, 8:46 PM@Incubating
@Input
@Option(option = "test-dry-run", description = "Simulate test execution.")
public abstract Property<Boolean> getDryRun();
Kevin Brightwell
06/26/2024, 3:42 PMSetProperty<>
from a provider that may be Missing
and not have the entire set conclude it is Missing
?Kelvin Chung
06/27/2024, 10:09 PMval task1 by tasks.registering(Zip::class) {
from(project.findProperty("sourcePath") as String?)
}
val task2 by tasks.registering(MyOtherTask::class) {
inputProperty.set(task1.flatMap { it.archiveFile }) // @get:InputFile
}
I'm seeing an error saying that inputProperty
isn't properly set because the file doesn't exist; is it because of something relating to the configuration of task1
? Should I work around this issue by subclassing Zip
for task1
?Andrew Tasso
06/28/2024, 12:10 PMGuilherme Delgado
07/01/2024, 9:59 PMSergej Koščejev
07/02/2024, 8:08 AMConfiguration.outgoing.artifacts
lazily? I need to add an artifact based on each domain object in a container but only for production objects, not tests. So I have to do it after the user configures the domain objects.Jan
07/02/2024, 2:43 PMclass MyPlugin : Plugin<Project> {
override fun apply(project: Project) {
val myPlugin = project.extensions.create("myPlugin", MyPluginExtension::class.java)
val kotlin = project.extensions.getByType(KotlinProjectExtension::class.java)
kotlin.sourceSets.forEach { sourceSet ->
val destination = project.layout.buildDirectory.dir("generated/myPlugin/${sourceSet.name}") // TODO: this feels wrong
sourceSet.kotlin.srcDir(destination)
project.tasks.register(
"generateMyCode${sourceSet.name}", // TODO: this feels wrong
GenerateCodeTask::class.java
) {
it.destination.set(destination)
}
}
}
}
The source set does get detected but registering all the tasks doesn't feel right. I thought of this because in Android you get all those tasks for each build variant, but like this many more tasks are registered (e.g. for *AndroidTest)
Follow up question: what's the correct way to attach this to e.g. the assemble task?Ruth
07/03/2024, 12:00 PMpublishing {
publications {
register("pluginMaven", MavenPublication::class) {
pom {
url.set("<https://github.com/europace/docker-publish-gradle-plugin>")
}
}
register("dockerPublishPluginPluginMarkerMaven", MavenPublication::class) {
pom {
url.set("<https://github.com/europace/docker-publish-gradle-plugin>")
}
}
}
}
}
But I get the error:
> Cannot add a Publication with name 'dockerPublishPluginPluginMarkerMaven' as a Publication with that name already exists.
Any idea what I am doing wrong?
I could not find any documentation about the adaption of the pom file.
Here they mention the publications, but I do not understand how to enrich the root pom fileJohn
07/03/2024, 7:34 PMapplication
java
and kotlin-dsl
etc for applying my custom plugin? i tried adding it in my plugin code, and my buildscripts were able to compile using it, but at runtime I got a classnotfound exception. i am guessing the extension property/function needs to be on the buildscript classpath. would adding it to a settings plugin, or custom wrapper work?Thomas Broyer
07/07/2024, 11:30 AMkotlin-dsl
produces Kotlin 1.4-compatible bytecode, compatible all the way down to Gradle 6.8.
IIUC (I'm not well versed into Kotlin compatibility), using Gradle 8.0–8.2 would only possibly allow for Kotlin 1.5 (3 versions down from 1.8), i.e. Gradle 7.2; and bumping to >=8.3 cuts that to Gradle 7.5 (Kotlin 1.6)
Do I understand properly? and what would you recommend?
(I'm thinking about rewriting from Kotlin to Java, but still need Kotlin for extension functions, but could then possibly just use kotlin("jvm")
rather than `embedded-kotlin`/`kotlin-dsl`; also, I don't think shipping variants is worse the hassle, this is for a small plugin, not AGP or KGP)Fredrick Eisele
07/16/2024, 3:04 PMMarc Hermans
07/19/2024, 9:06 AMBenoît
07/23/2024, 9:56 AMDidier Villevalois
07/24/2024, 8:06 AM@InputFile
input, and I use an @OutputDirectory
for the location where the document is generated.
However, I need to execute the input Kotlin script to determine the other markdown input files, which is already half of the generation process. I understand that I shouldn't/cannot modify the tasks input during the task execution of a DefaultTask
(any task?).
Don't I have any other choice than to do twice the script execution, once at task configuration to determine all the input paths (which can be scattered in the project, so cannot use an @InputDirectory
) and once more at task execution to do the generation itself?Kelvin Chung
07/24/2024, 7:53 PMfun AntBuilder.taskdef(name: String, classname: String, classpath: Configuration) = withGroovyBuilder {
"taskdef"("name" to name, "classname" to classname, "classpath" to classpath.asPath)
}
class MyPlugin : Plugin<Project> {
override fun apply(project: Project) {
val configuration = ...
project.ant.taskdef("someTask", "someClass", configuration)
}
}
Now, suppose I have a task that does this:
abstract class MyTask : DefaultTask() {
@TaskAction
fun run() {
ant.withGroovyBuilder {
// something with "someTask"
}
}
}
Would that be well-formed, or do I need to apply the taskdef
in MyTask
- ie. introduce a @Classpath
property?Alexey Loubyansky
07/25/2024, 8:56 PM