Right now, the `zipBaseName` variable in various publish.gradle files
contains the group ID and artifact ID for use by the combiner, however,
they are also duplicated in `artifactGroupId` and `baseArtifactId`,
leading to potential mistakes if they aren't updated together. This
fixes that by adding a new utility function `makeZipBaseName` to
automatically create the right name given a group ID and artifact ID.
This also fixes publishing for thirdparty subprojects, which didn't
update `zipBaseName`.
The deprecation message was:
```
The `archives` configuration added by the `base` plugin has been
deprecated and will be removed in Gradle 10.0.0. Adding artifacts to the
`archives` configuration will now result in a deprecation warning. If
you want the artifact built when running the `assemble` task, you should
add the artifact (or the task that produces it) as a dependency of the
`assemble` task directly.
val specialJar = tasks.register<Jar>("specialJar") {
archiveBaseName.set("special")
from("build/special")
}
tasks.named("assemble") {
dependsOn(specialJar)
}
```
This adds support for two serialization formats for complex data types:
- Protobuf for complex objects with variable length internals that need forward and backward wire compatibility (lower speed, more flexible)
- Raw struct (ByteBuffer-style) for fixed-length objects (higher speed, less flexible)
Deserialization can be done either by creating a new object (for immutable objects) or overwriting the contents of an existing object (for mutable objects).
Implementing classes should provide inner classes that implement the Protobuf or Struct interface (in Java) or specialize the wpi::Protobuf or wpi::Struct struct (in C++). It is possible for classes to implement both. If the class itself does not implement serialization, it's possible for third parties/users to provide an implementation instead.
Uses the Google protobuf implementation for C++ and the QuickBuffers alternative protobuf implementation for Java.
This works around an exit race with wpi::Now() on Rio; it was overridden
to call HAL_GetFPGATime(), which calls chipobject, but on exit, because
there was not a library dependency, the chipobject could be destroyed
prior to wpiutil/wpinet being shut down.
Also deletes object files.
Both of these things are only done on the build server (-PbuildServer flag).
This will remove all test folders, which removes lots of copies of dependencies.
This also fixes an issue where gtest exectubables were installed for cross builds, even though they should not have been.
This makes it much more user-friendly to use simulation classes without needing
to ifdef for C++ to avoid linker errors or be very careful about construction
to avoid runtime errors in Java.
With the new extraction method, we would need to provide an opencv. However, all of our tools that use opencv use an alternate version of OpenCV, so that would interfere.
This adds an artifact where opencv is statically linked into cscore, but wpiutil is a shared dependency. This solves some shared state hacks, and the extraction works so much better, so its worth making this change to allow that
* Add new combined native class loader
Allows us to extract a list of binaries that depend on each other, and load them successfully
It is correct that there is no implementation in wpiutil for the new native method. That is a requirement, because its needed to load the libraries, and we cant load the wpiutiljni native library since it depends on wpiutil. Instead we have a separate library built with the tools plugin that handles everything
This class provides an easy way to forward local ports to another host/port.
This is primarily useful to provide a way to access Ethernet-connected devices
from a computer tethered to the RoboRIO USB port.
The most natural spot to put the shared implementation of this class was into
wpiutil, so a wpiutilJNI library has been added.
