Team2890/allwpilib
4
0
Fork 0
mirror of https://github.com/wpilibsuite/allwpilib synced 2026-06-19 00:41:43 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
allwpilib/commandsv3/build.gradle

52 lines
1.4 KiB
Groovy
Raw Permalink Normal View History

[commands] Add Commands v3 framework (#6518) The framework fundamentally relies on the continuation API added in Java 21 (which is currently internal to the JDK). Continuations allow for call stacks to be saved to the heap and resumed later. The async framework allows command bodies to be written in an imperative style. However, an async command will need to be actively cooperative and periodically call coroutine.yield() in loops to yield control back to the command scheduler to let it process other commands. There are also some other additions like priority levels (as opposed to a blanket yes/no for ignoring incoming commands), factories requiring names be provided for commands, and the scheduler tracking all running commands and not just the highest-level groups. However, those changes aren't unique to an async framework, and could just as easily be used in a traditional command framework.
2025-10-10 16:47:22 -04:00
ext {
useJava = true
useCpp = false
baseId = 'commands3'
groupId = 'org.wpilib'
nativeName = 'commands3'
devMain = 'org.wpilib.commands3.DevMain'
}
apply from: "${rootDir}/shared/java/javacommon.gradle"
evaluationDependsOn(':wpiutil')
evaluationDependsOn(':ntcore')
evaluationDependsOn(':hal')
evaluationDependsOn(':wpimath')
evaluationDependsOn(':wpilibj')
dependencies {
annotationProcessor project(':javacPlugin')
implementation project(':wpiannotations')
implementation project(':wpiutil')
implementation project(':wpinet')
implementation project(':ntcore')
implementation project(':hal')
implementation project(':wpimath')
implementation project(':wpilibj')
[build] Migrate to Gradle version catalogs (#8524) Also fixes the google compile-testing library to 0.23.0 (the latest available at time of writing) instead of a wildcard Jackson versions were inconsistent across projects; most were on 2.19.2, but the fields subproject was on 2.15.2. All projects are now on 2.19.2 for consistency
2026-02-20 18:31:33 -05:00
api(libs.quickbuf.runtime)
[commands] Add Commands v3 framework (#6518) The framework fundamentally relies on the continuation API added in Java 21 (which is currently internal to the JDK). Continuations allow for call stacks to be saved to the heap and resumed later. The async framework allows command bodies to be written in an imperative style. However, an async command will need to be actively cooperative and periodically call coroutine.yield() in loops to yield control back to the command scheduler to let it process other commands. There are also some other additions like priority levels (as opposed to a blanket yes/no for ignoring incoming commands), factories requiring names be provided for commands, and the scheduler tracking all running commands and not just the highest-level groups. However, those changes aren't unique to an async framework, and could just as easily be used in a traditional command framework.
2025-10-10 16:47:22 -04:00
testAnnotationProcessor project(':javacPlugin')
[epilogue] Fix v3 scheduler incompatibility with epilogue (#8458) Was caused by checking assignability like`Protobuf<Scheduler, ProtoMessage>` instead of `Protobuf<Scheduler, ? extends ProtoMessage<?>>` This epilogue bug would have also applied to other protobuf-serializable types
2025-12-07 01:38:10 -05:00
testAnnotationProcessor project(':epilogue-processor')
[build] Migrate to Gradle version catalogs (#8524) Also fixes the google compile-testing library to 0.23.0 (the latest available at time of writing) instead of a wildcard Jackson versions were inconsistent across projects; most were on 2.19.2, but the fields subproject was on 2.15.2. All projects are now on 2.19.2 for consistency
2026-02-20 18:31:33 -05:00
testImplementation(libs.bundles.mockito)
[epilogue] Fix v3 scheduler incompatibility with epilogue (#8458) Was caused by checking assignability like`Protobuf<Scheduler, ProtoMessage>` instead of `Protobuf<Scheduler, ? extends ProtoMessage<?>>` This epilogue bug would have also applied to other protobuf-serializable types
2025-12-07 01:38:10 -05:00
testImplementation project(':epilogue-runtime')
[commands] Add Commands v3 framework (#6518) The framework fundamentally relies on the continuation API added in Java 21 (which is currently internal to the JDK). Continuations allow for call stacks to be saved to the heap and resumed later. The async framework allows command bodies to be written in an imperative style. However, an async command will need to be actively cooperative and periodically call coroutine.yield() in loops to yield control back to the command scheduler to let it process other commands. There are also some other additions like priority levels (as opposed to a blanket yes/no for ignoring incoming commands), factories requiring names be provided for commands, and the scheduler tracking all running commands and not just the highest-level groups. However, those changes aren't unique to an async framework, and could just as easily be used in a traditional command framework.
2025-10-10 16:47:22 -04:00
}
sourceSets.main.java.srcDir "${projectDir}/src/generated/main/java"
sourceSets.main.resources.srcDir "${projectDir}/src/main/proto"
test {
testLogging {
outputs.upToDateWhen {false}
showStandardStreams = true
}
// For reflective access to the continuation classes
jvmArgs += [
'--add-opens',
'java.base/jdk.internal.vm=ALL-UNNAMED',
'--add-opens',
'java.base/java.lang=ALL-UNNAMED',
]
}
Reference in New Issue Copy Permalink