Java Constraint Solver to solve vehicle routing, employee rostering, task assignment, conference scheduling and other planning problems.

Overview

OptaPlanner

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 master, 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.

Comments
  • PLANNER-2474 optaplanner CI

    PLANNER-2474 optaplanner CI

    JIRA

    https://issues.redhat.com/browse/PLANNER-2474

    Referenced pull requests

    • https://github.com/kiegroup/optaplanner/pull/1440
    • https://github.com/kiegroup/optaplanner-quickstarts/pull/141
    • https://github.com/kiegroup/kogito-pipelines/pull/215
    • https://github.com/kiegroup/optaweb-employee-rostering/pull/677
    • https://github.com/kiegroup/optaweb-vehicle-routing/pull/547

    https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml is pointing to a specific branch, it should be dynamically calculated, this is a pending improvement on build-chain tool https://github.com/kiegroup/github-action-build-chain/issues/117

    opened by Ginxo 252
  • Add Score.abs() for GreatDelugeAlgorithm.

    Add Score.abs() for GreatDelugeAlgorithm.

    Hi there,

    I noticed one tiny problem in the great deluge algorithm. In the end of each step, the current water level will be updated by a certain amount. It works well when the configuration is set to be increasing by a fixed score. However, if I set the increment as a ratio (Using ratio is a brilliant idea by the way), then the algorithm will only work when the starting water level is negative. In fact, to make sure the water level keep increasing, every increment of water level should be positive. But it will be negative when the starting water level is positive. So .negate() is not suitable for all scenarios, for example, when someone has more reward score than penalty score. Maybe taking absolute value is a better idea. I add an abs.() function for the score so that the certain amount will always be positive and the water level can keep increasing.

    JIRA

    Referenced pull requests

    Checklist

    • [ ] Documentation updated if applicable.
    • [ ] Upgrade recipe provided if applicable.
    How to replicate CI configuration locally?

    Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

    build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

    How to retest this PR or trigger a specific build:
    • for pull request checks
      Please add comment: Jenkins retest this

    • for a specific pull request check
      please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] tests

    • for a full downstream build

      • for jenkins job: please add comment: Jenkins run fdb
      • for github actions job: add the label run_fdb
    • for a compile downstream build
      please add comment: Jenkins run cdb

    • for a full production downstream build
      please add comment: Jenkins execute product fdb

    • for an upstream build
      please add comment: Jenkins run upstream

    • for quarkus branch checks
      Run checks against Quarkus current used branch
      Please add comment: Jenkins run quarkus-branch

    • for a quarkus branch specific check
      Run checks against Quarkus current used branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] quarkus-branch

    • for quarkus main checks
      Run checks against Quarkus main branch
      Please add comment: Jenkins run quarkus-main

    • for a specific quarkus main check
      Run checks against Quarkus main branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] quarkus-branch

    • for native checks
      Run native checks
      Please add comment: Jenkins run native

    • for a specific native check
      Run native checks Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] native

    • for mandrel checks
      Run native checks against Mandrel image Please add comment: Jenkins run mandrel

    • for a specific mandrel check
      Run native checks against Mandrel image
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] mandrel

    CI Status

    You can check OptaPlanner repositories CI status from Chain Status webpage.

    opened by FreyaLJX 95
  • PLANNER-2443: Fix Quarkus native: only check @PlanningSolution and @PlanningEntity members, make Substitute_ConfigUtil newInstance.signature match ConfigUtil.newInstance signature

    PLANNER-2443: Fix Quarkus native: only check @PlanningSolution and @PlanningEntity members, make Substitute_ConfigUtil newInstance.signature match ConfigUtil.newInstance signature

    I noticed the native build was broken when trying CR3; it appears the PLANNING_SCORE member was either copied or moved to ScoreDescriptor, causing code to be generated for it (although it a static field, which cause issues, thus native build failing)

    JIRA

    Referenced pull requests

    Checklist

    • [ ] Documentation updated if applicable.
    • [ ] Upgrade recipe provided if applicable.
    How to retest this PR or trigger a specific build:
    • for a pull request build please add comment: Jenkins retest this
    • for a full downstream build please add comment: Jenkins run fdb
    • for a compile downstream build please add comment: Jenkins run cdb
    • for a full production downstream build please add comment: Jenkins execute product fdb
    • for an upstream build please add comment: Jenkins run upstream
    • for a Quarkus LTS check please add comment: Jenkins run LTS
    • for a Native check please add comment: Jenkins run native
    opened by Christopher-Chianelli 89
  • Desugared use of APIs incompatible with Android

    Desugared use of APIs incompatible with Android

    Android unfortunately supports only a subset of the current JDK API. This has so far not been a problem for OptaPlanner, but after some recent changes OptaPlanner apparently started using some of the unsupported APIs, causing runtime crashes.

    ServiceLoader.findFirst() is not currently supported by Android. Collection.toArray(IntFunction<T[]>) is available as of Android API Level 33 but is not available as a "desugared" API yet, which means it can not be used in apps that want to maintain backwards compatibility.

    Fortunately, this is easily fixed. Both APIs are convenience methods, not adding any crucial new features. This PR replaces their use with the slightly-less-nice-looking-but-Android-compatible counterparts. I didn't touch any usage for example in the Drools module, as that isn't compatible with Android in the first place.

    opened by Namnodorel 84
  • Fix key in documentation for log separation

    Fix key in documentation for log separation

    Change the key for the sifting appender to subSingleBenchmark.name in the documentation as referenced in the code at https://github.com/kiegroup/optaplanner/blob/5e36aecfa6b18b6f36e4e019fed5b70449176fea/optaplanner-benchmark/src/main/java/org/optaplanner/benchmark/impl/SubSingleBenchmarkRunner.java#L28

    opened by simontiffert 82
  • Fix void with-method

    Fix void with-method

    Trivial two-line bug fix.

    CustomPhaseConfig.withCustomProperties(Map) was void. Now returns the instance after setting the property.

    JIRA

    There is no issue for this, as far as I know.

    opened by chrfin-4 82
  • Bump xstream from 1.4.18 to 1.4.19 in /build/optaplanner-build-parent

    Bump xstream from 1.4.18 to 1.4.19 in /build/optaplanner-build-parent

    Bumps xstream from 1.4.18 to 1.4.19.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 82
  • java.lang.IllegalStateException

    java.lang.IllegalStateException

    When I run an flight crew scheduling problem solve,it cause such problem.

    Caused by: java.lang.IllegalStateException: The entity (AB071@2018-01-01-0) has a variable (employee) with value (Chad Q. Green) which has a sourceVariableName variable (flightAssignmentSet) with a value ([AB003@2018-01-01-0, AB019@2018-01-01-0, AB047@2018-01-01-0, AB070@2018-01-01-0]) which already contained the entity (AB071@2018-01-01-0). Verify the consistency of your input problem for that bi-directional relationship.

    What's wrong with this problem?

    opened by xhmywf 81
  • Enable FilteringEntitySelector to support list iterator

    Enable FilteringEntitySelector to support list iterator

    Hello 👋

    I ran into difficulties benchmarking with a dataset that included pinned entities, and came to learn the cause was I couldn't run VARIABLE_NEIGHBORHOOD_DESCENT with pinned entities, because FilteringEntitySelector#listIterator had not yet been implemented.

    I was interested in the internals so had a stab at doing this by extending the existing UpcomingSelectionIterator into a new class that could also iterate backwards, and using that in the implementation.

    Updated unit tests to include this, though wasn't sure if you guys would want a more comprehensive integration test as well? e.g. could add some pinned entities into the tennis example here for instance, and run one of the tennis tests with variable descent to check it all works end-to-end, if that's advisable.

    Let me know if there's any questions or feedback, or if there's other reasons I missed for why this can't/shouldn't be supported.

    JIRA

    Was not explicitly dealing with a JIRA ticket, though I came across this one that's related: https://issues.redhat.com/browse/PLANNER-196 (status "won't fix")

    opened by artysidorenko 72
  • KOGITO-5070 Setup multijob pipeline

    KOGITO-5070 Setup multijob pipeline

    https://issues.redhat.com/browse/KOGITO-5070

    This will allow to run Jenkins pr check, if multijob-pr label is set, in separate jobs. Also, each project check is responsible to set correct Jenkinsfile and this avoids to rewrite the commands to run in each repo for the downstream projects. Also, this add kogito-apps and kogito-examples checks to Optaplanner (but can be removed if needed).

    For now, this does not replace the current global PR check. It is only activated with the multijob-pr label.

    Depends on https://github.com/kiegroup/kogito-pipelines/pull/148

    Related PRs:

    • https://github.com/kiegroup/kogito-runtimes/pull/1284
    • https://github.com/kiegroup/optaplanner/pull/1304
    • https://github.com/kiegroup/kogito-apps/pull/805
    • https://github.com/kiegroup/kogito-examples/pull/671

    Final note: Current run PR checks for this PR are from my custom folder on Jenkins and will be moved to Kogito folder once all the PRs are merged. Please do not use before ...

    opened by radtriste 71
  • [bot]: Bump xstream from 1.4.19 to 1.4.20

    [bot]: Bump xstream from 1.4.19 to 1.4.20

    Bumps xstream from 1.4.19 to 1.4.20.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 68
  • [bot]: Bump versions-maven-plugin from 2.14.1 to 2.14.2

    [bot]: Bump versions-maven-plugin from 2.14.1 to 2.14.2

    Bumps versions-maven-plugin from 2.14.1 to 2.14.2.

    Release notes

    Sourced from versions-maven-plugin's releases.

    2.14.2

    Changes

    🚀 New features and improvements

    🐛 Bug Fixes

    📦 Dependency updates

    👻 Maintenance

    Commits
    • 374ddab [maven-release-plugin] prepare release 2.14.2
    • 2b9bdb7 Bump wagon-provider-api from 3.5.2 to 3.5.3
    • 67c1800 Resolves #872: Make allowSnapshots an explicit argument in lookupDependencyUp...
    • 2fe2c3d Manage transitive dependencies version for security updates
    • 1130350 Upgrade com.fasterxml.woodstox:woodstox-core to 6.4.0
    • 8f2fd07 Project dependencies maintenance - move versions to dependencyManagement
    • 2bed457 Add a simple cache for ComparableVersions
    • 2d7a157 Bump actions/stale from 6 to 7
    • 4546a4e Fixes #866: Require maven 3.2.5
    • 5ee419d Bump mockito-inline from 4.9.0 to 4.10.0
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 65
  • PLANNER-2847: OptaPlanner version should be updated in kie-benchmarks…

    PLANNER-2847: OptaPlanner version should be updated in kie-benchmarks…

    … when the release branch is created

    JIRA

    PLANNER-2874

    Referenced pull requests

    Checklist

    • [ ] Documentation updated if applicable.
    • [ ] Release notes updated if applicable.
    • [ ] Upgrade recipe provided if applicable.
    How to replicate CI configuration locally?

    Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

    build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

    How to retest this PR or trigger a specific build:
    • for pull request checks
      Please add comment: Jenkins retest this

    • for a specific pull request check
      please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] tests

    • for a full downstream build

      • for jenkins job: please add comment: Jenkins run fdb
      • for github actions job: add the label run_fdb
    • for a compile downstream build
      please add comment: Jenkins run cdb

    • for a full production downstream build
      please add comment: Jenkins execute product fdb

    • for an upstream build
      please add comment: Jenkins run upstream

    • for quarkus branch checks
      Run checks against Quarkus current used branch
      Please add comment: Jenkins run quarkus-branch

    • for a quarkus branch specific check
      Run checks against Quarkus current used branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for quarkus main checks
      Run checks against Quarkus main branch
      Please add comment: Jenkins run quarkus-main

    • for a specific quarkus main check
      Run checks against Quarkus main branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for quarkus lts checks
      Run checks against Quarkus lts branch
      Please add comment: Jenkins run quarkus-lts

    • for a specific quarkus lts check
      Run checks against Quarkus lts branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-lts

    • for native checks
      Run native checks
      Please add comment: Jenkins run native

    • for a specific native check
      Run native checks Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] native

    • for mandrel checks
      Run native checks against Mandrel image Please add comment: Jenkins run mandrel

    • for a specific mandrel check
      Run native checks against Mandrel image
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] mandrel

    • for mandrel lts checks
      Run native checks against Mandrel image and quarkus lts branch Please add comment: Jenkins run mandrel-lts

    • for a specific mandrel lts check
      Run native checks against Mandrel image and quarkus lts branch Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] mandrel-lts

    CI Status

    You can check OptaPlanner repositories CI status from Chain Status webpage.

    How to backport a pull request to a different branch?

    In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

    NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

    Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

    If something goes wrong, the author will be notified and at this point a manual backporting is needed.

    NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

    opened by mbiarnes 0
  • [DO NOT MERGE] PLANNER-2869 Investigate migration to Quarkus 3

    [DO NOT MERGE] PLANNER-2869 Investigate migration to Quarkus 3

    JIRA

    https://issues.redhat.com/browse/PLANNER-2869

    Referenced pull requests

    Checklist

    • [ ] Documentation updated if applicable.
    • [ ] Release notes updated if applicable.
    • [ ] Upgrade recipe provided if applicable.
    How to replicate CI configuration locally?

    Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

    build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

    How to retest this PR or trigger a specific build:
    • for pull request checks
      Please add comment: Jenkins retest this

    • for a specific pull request check
      please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] tests

    • for a full downstream build

      • for jenkins job: please add comment: Jenkins run fdb
      • for github actions job: add the label run_fdb
    • for a compile downstream build
      please add comment: Jenkins run cdb

    • for a full production downstream build
      please add comment: Jenkins execute product fdb

    • for an upstream build
      please add comment: Jenkins run upstream

    • for quarkus branch checks
      Run checks against Quarkus current used branch
      Please add comment: Jenkins run quarkus-branch

    • for a quarkus branch specific check
      Run checks against Quarkus current used branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for quarkus main checks
      Run checks against Quarkus main branch
      Please add comment: Jenkins run quarkus-main

    • for a specific quarkus main check
      Run checks against Quarkus main branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for quarkus lts checks
      Run checks against Quarkus lts branch
      Please add comment: Jenkins run quarkus-lts

    • for a specific quarkus lts check
      Run checks against Quarkus lts branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-lts

    • for native checks
      Run native checks
      Please add comment: Jenkins run native

    • for a specific native check
      Run native checks Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] native

    • for mandrel checks
      Run native checks against Mandrel image Please add comment: Jenkins run mandrel

    • for a specific mandrel check
      Run native checks against Mandrel image
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] mandrel

    • for mandrel lts checks
      Run native checks against Mandrel image and quarkus lts branch Please add comment: Jenkins run mandrel-lts

    • for a specific mandrel lts check
      Run native checks against Mandrel image and quarkus lts branch Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts] mandrel-lts

    CI Status

    You can check OptaPlanner repositories CI status from Chain Status webpage.

    How to backport a pull request to a different branch?

    In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

    NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

    Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

    If something goes wrong, the author will be notified and at this point a manual backporting is needed.

    NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

    do_not_merge 
    opened by rsynek 3
  • [bot]: Bump quarkus-operator-sdk from 4.0.5 to 5.0.0

    [bot]: Bump quarkus-operator-sdk from 4.0.5 to 5.0.0

    Bumps quarkus-operator-sdk from 4.0.5 to 5.0.0.

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 12
  • [bot]: Bump maven-javadoc-plugin from 3.0.1 to 3.4.1

    [bot]: Bump maven-javadoc-plugin from 3.0.1 to 3.4.1

    Bumps maven-javadoc-plugin from 3.0.1 to 3.4.1.

    Release notes

    Sourced from maven-javadoc-plugin's releases.

    3.4.1

    📦 Dependency updates

    3.4.0

    What's Changed

    Full Changelog: https://github.com/apache/maven-javadoc-plugin/compare/maven-javadoc-plugin-3.3.2...maven-javadoc-plugin-3.4.0

    3.3.2

    What's Changed

    ... (truncated)

    Commits
    • a5db96e [maven-release-plugin] prepare release maven-javadoc-plugin-3.4.1
    • a10f0b1 [MJAVADOC-723] Upgrade Maven Reporting API to 3.1.1/Complete with Maven Repor...
    • c19dba2 Skip Java 9-14 in reproducible test
    • 26d84b2 Add notimestamp for reproducible builds test
    • 92ce668 Ignore Maven Core updates
    • bacc078 Add Integration Test for reproducible builds
    • 497f80f [MJAVADOC-719] - Update Maven Archiver to 3.6.0
    • 34b501d Bump assertj-core from 3.21.0 to 3.23.1
    • b928970 Bump spring-webmvc in /src/it/projects/MJAVADOC-434_fixcompile
    • 4306c92 Bump mockito-core from 4.1.0 to 4.4.0
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies java 
    opened by dependabot[bot] 66
  • Reuse abstract iterators

    Reuse abstract iterators

    How to replicate CI configuration locally?

    Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

    build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

    How to retest this PR or trigger a specific build:
    • for pull request checks
      Please add comment: Jenkins retest this

    • for a specific pull request check
      please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] tests

    • for a full downstream build

      • for jenkins job: please add comment: Jenkins run fdb
      • for github actions job: add the label run_fdb
    • for a compile downstream build
      please add comment: Jenkins run cdb

    • for a full production downstream build
      please add comment: Jenkins execute product fdb

    • for an upstream build
      please add comment: Jenkins run upstream

    • for quarkus branch checks
      Run checks against Quarkus current used branch
      Please add comment: Jenkins run quarkus-branch

    • for a quarkus branch specific check
      Run checks against Quarkus current used branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for quarkus main checks
      Run checks against Quarkus main branch
      Please add comment: Jenkins run quarkus-main

    • for a specific quarkus main check
      Run checks against Quarkus main branch
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] quarkus-branch

    • for native checks
      Run native checks
      Please add comment: Jenkins run native

    • for a specific native check
      Run native checks Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] native

    • for mandrel checks
      Run native checks against Mandrel image Please add comment: Jenkins run mandrel

    • for a specific mandrel check
      Run native checks against Mandrel image
      Please add comment: Jenkins (re)run [optaplanner|optaplanner-quickstarts|optaweb-vehicle-routing] mandrel

    CI Status

    You can check OptaPlanner repositories CI status from Chain Status webpage.

    opened by yurloc 1
Owner
KIE (Drools, OptaPlanner and jBPM)
Code of the Drools rule engine, OptaPlanner constraint solver and jBPM workflow engine.
KIE (Drools, OptaPlanner and jBPM)
An open-source Java library for Constraint Programming

Documentation, Support and Issues Contributing Download and installation Choco-solver is an open-source Java library for Constraint Programming. Curre

null 607 Jan 3, 2023
Car-Sequencing-Problem - Car-Sequencing Problem solved with Constraint Programming approach

Car-Sequencing problem solved with Constraint Programming : Problem Description : Cars in a production line can be configured with various options. A

Anas OUBAHA 4 Sep 7, 2022
A Light-weight Job Scheduling Framework

Sundial A Lightweight Job Scheduling Framework for Java. In a Nutshell Sundial makes adding scheduled jobs to your Java application a walk in the park

Knowm 262 Dec 9, 2022
Solutions of many problems from HackerRank

Solutions of some problems from HackerRank made specially for beginners and who are in the intermediate level If you like this project, please leave m

Mohamed Metwalli 35 Nov 14, 2022
Solutions to HackerRank problems

HackerRank This is my solutions to HackerRank problems using java, might not be the best solution but at least i tried Algorithms Subdomain Difficulty

Yasir Haq 7 Apr 4, 2022
The CSES Problem Set is a collection of algorithmic programming problems.

The CSES Problem Set is a collection of algorithmic programming problems. The goal of the project is to create a comprehensive high quality problem se

Mohd Abdul Azeem 1 Jan 5, 2022
Discord4J is a fast, powerful, unopinionated, reactive library to enable quick and easy development of Discord bots for Java, Kotlin, and other JVM languages using the official Discord Bot API.

Discord4J is a fast, powerful, unopinionated, reactive library to enable quick and easy development of Discord bots for Java, Kotlin, and other JVM languages using the official Discord Bot API.

null 1.5k Jan 4, 2023
Client for anarchy servers that has bots / auto-modules and other stuff.

AutoBot is a module styled client for anarchy servers that offers bots and auto-modules like ElytraBot which is a pathfinding bot for elytras

null 43 Dec 27, 2022
Utility for developers and QAs what helps minimize time wasting on writing the same data for testing over and over again. Made by Stfalcon

Stfalcon Fixturer A Utility for developers and QAs which helps minimize time wasting on writing the same data for testing over and over again. You can

Stfalcon LLC 31 Nov 29, 2021
A tool ot export, analyse and visualize your transactions, rewards and commissions of your liquidity mining pools or DEX transactions

A tool ot export, analyse and visualize your transactions, rewards and commissions of your liquidity mining pools or DEX transactions.

Adam·Michael 15 Mar 11, 2022
Object-Oriented Java primitives, as an alternative to Google Guava and Apache Commons

Project architect: @victornoel ATTENTION: We're still in a very early alpha version, the API may and will change frequently. Please, use it at your ow

Yegor Bugayenko 691 Dec 27, 2022
Dex : The Data Explorer -- A data visualization tool written in Java/Groovy/JavaFX capable of powerful ETL and publishing web visualizations.

Dex Dex : The data explorer is a powerful tool for data science. It is written in Groovy and Java on top of JavaFX and offers the ability to: Read in

Patrick Martin 1.3k Jan 8, 2023
Java Collections till the last breadcrumb of memory and performance

Koloboke A family of projects around collections in Java (so far). The Koloboke Collections API A carefully designed extension of the Java Collections

Roman Leventov 967 Nov 14, 2022
An utility to usage efficience ByteArray in Kotlin and Java.

An utility to usage efficience ByteArray in Kotlin and Java.

Cuong V. Nguyen 5 Sep 29, 2021
Fork of JProcesses with additional features and enhancements. Get cross-platform process details in Java.

Fork of JProcesses with additional features and enhancements. Get cross-platform process details in Java. Add this as dependency to your project via Maven/Gradle/Sbt/Leinigen (requires Java 7 or higher).

Osiris-Team 4 Mar 17, 2022
Java lib for monitoring directories or individual files via java.nio.file.WatchService

ch.vorburger.fswatch Java lib for monitoring directories or individual files based on the java.nio.file.WatchService. Usage Get it from Maven Central

Michael Vorburger ⛑️ 21 Jan 7, 2022
Tencent Kona JDK11 is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-Term Support(LTS) with quarterly updates. Tencent Kona JDK11 is certified as compatible with the Java SE standard.

Tencent Kona JDK11 Tencent Kona JDK11 is a no-cost, production-ready distribution of the Open Java Development Kit (OpenJDK), Long-Term Support(LTS) w

Tencent 268 Dec 16, 2022
This repository contains Java programs to become zero to hero in Java.

This repository contains Java programs to become zero to hero in Java. Data Structure programs topic wise are also present to learn data structure problem solving in Java. Programs related to each and every concep are present from easy to intermidiate level

Sahil Batra 15 Oct 9, 2022
Preparation and practice for coding interviews

Coding Interviews Preparation and practice for coding interviews Hope you enjoy and help is more than welcome :) Problems by Dificulty A1 1D problems,

Caravana Cloud 21 Oct 25, 2022