/optaplanner

AI constraint solver in Java to optimize the vehicle routing problem, employee rostering, task assignment, maintenance scheduling, conference scheduling and other planning problems.

Primary LanguageJavaApache License 2.0Apache-2.0

OptaPlanner

Ask question on Stack Overflow Join Zulip Chat

Quality Gate Status Reliability Rating Security Rating Maintainability Rating Lines of Code Coverage

Looking for Quickstarts?

OptaPlanner’s quickstarts have moved to optaplanner-quickstarts repository.

Quick development start

To build and run from source:

$ mvn clean install -DskipTests
$ cd optaplanner-examples
$ mvn exec:java

To develop with IntelliJ IDEA, Eclipse or VSCode, open the root pom.xml as a new project and configure a Run/Debug configuration like this:

  • Type: Application

  • Main class: org.optaplanner.examples.app.OptaPlannerExamplesApp

  • VM options: -Xmx2G -server (memory only needed when using the big datasets in the examples)

  • Program arguments: (none)

  • Working directory: $MODULE_DIR$ (must resolve to optaplanner-examples directory)

  • Use classpath of module: optaplanner-examples

Starter issues

If you’re just starting out with OptaPlanner and want to contribute, take a look at our starter issues. They’re specifically chosen to be easier for first time contributors.

Developing Drools, OptaPlanner and jBPM

If you want to build or contribute to a kiegroup project, read this document.

It will save you and us a lot of time by setting up your development environment correctly. It solves all known pitfalls that can disrupt your development. It also describes all guidelines, tips and tricks. If you want your pull requests (or patches) to be merged into main, please respect those guidelines.

Code style

OptaPlanner has adopted the Quarkus code style, enforces it, and automatically formats code during the build. To setup your IDE, please see the IDE Setup Instructions.

Definition of Done

To consider any individual ticket "Done", following requirements must be satisfied:

  1. Every change must go through PR; source code of both the feature/bugfix and its tests have been reviewed.

  2. Documentation (if applicable) exists and has been reviewed.

  3. There is test coverage proving the feature works and tests are passing.

In order to avoid introducing unstable features, the PR will be merged only after these points have been fulfilled. For PRs contributed by community the core team will assist with making the functionality meet these conditions.