timefold-solver
timefold-solver copied to clipboard
TimefoldAI
Solver Core: split up gizmo generation and gizmo runtime code in seperate packages
The gizmo generated runtime code should not import io.gizmo.
The (MemberAccessor)Factory should generate the bytecode for non-quarkus cases and require gizmo on classpath at runtime. Quarkus does that during the build, so no need for gizmo on the classpath. The code generating code and the runtime code must be in separate packages (runtime/deployment?)
Related issues:
- GizmoMemberDescriptor naming. It does not extend MemberDescriptor.
- GizmoClassLoader naming. It's part of Timefold.
- ...
Is there any support for Spring Boot native images planned? I assume it should be possible to use Gizmo to build the bytecode ahead of time there as well.
I'm still digging into Spring Boot native images, so I cannot contribute anything of use yet.
@thimmwork We want to keep our support for Quarkus and Spring Boot functionally equivalent, so native support should eventually show up for Spring Boot as well. However, it is not on the short-term roadmap.
If you want to work on this, pull requests are welcome! Doing it using Gizmo would be preferred, as then we could reuse much of the Quarkus code instead of duplicating the logic with some other library.
