Optaplanner

KIE (Drools, OptaPlanner and jBPM)

Last update: Jan 9, 2023

Overview

OptaPlanner

www.optaplanner.org

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:

Every change must go through PR; source code of both the feature/bugfix and its tests have been reviewed.
Documentation (if applicable) exists and has been reviewed.
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
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.
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
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

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

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

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
Bumps xstream from 1.4.18 to 1.4.19.

Commits

See full diff in compare view

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

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

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
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 assertj-core from 3.23.1 to 3.24.0
Bumps assertj-core from 3.23.1 to 3.24.0.

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
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
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 8
[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

[MJAVADOC-723] - Upgrade Maven Reporting API to 3.1.1/Complete with Maven Reporting Impl 3.2.0 (#158) @pzygielo

Skip Java 9-14 in reproducible test (#155) @jorsol

Add Integration Test for reproducible builds (#152) @jorsol

[MJAVADOC-719] - Update Maven Archiver to 3.6.0 (#150) @jorsol

📦 Dependency updates

Bump assertj-core from 3.21.0 to 3.23.1 (#143) @dependabot

Bump spring-webmvc from 4.3.29.RELEASE to 5.2.21.RELEASE in /src/it/projects/MJAVADOC-434_fixcompile (#135) @dependabot

Bump mockito-core from 4.1.0 to 4.4.0 (#133) @dependabot

3.4.0

What's Changed

(doc) Update plugin' configuration parameter (MJAVADOC-475) by @pzygielo in apache/maven-javadoc-plugin#123

(doc) Update plugin' configuration parameter (MJAVADOC-475) by @pzygielo in apache/maven-javadoc-plugin#124

(doc) Fix spurious Javadoc @param tag by @pzygielo in apache/maven-javadoc-plugin#125

use shared gh action/release-drafter by @olamy in apache/maven-javadoc-plugin#128

Bump commons-io from 2.2 to 2.7 in /src/it/projects/MJAVADOC-437/module2 by @dependabot in apache/maven-javadoc-plugin#132

Bump junit from 4.12 to 4.13.1 in /src/it/projects/MJAVADOC-498_modulepath by @dependabot in apache/maven-javadoc-plugin#131

Bump plexus-archiver from 4.2.6 to 4.2.7 by @dependabot in apache/maven-javadoc-plugin#118

Bump maven-archiver from 3.5.1 to 3.5.2 by @dependabot in apache/maven-javadoc-plugin#117

[MJAVADOC-714] Upgrade to Maven 3.2.5 by @michael-o in apache/maven-javadoc-plugin#134

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

[MJAVADOC-530] - Clean up additionalparam documentation by @marschall in apache/maven-javadoc-plugin#6

[MJAVADOC-538] Filter out 'Picked up' by @risdenk in apache/maven-javadoc-plugin#11

[MJAVADOC-546] Allow to generate report in Spanish locale by @belingueres in apache/maven-javadoc-plugin#12

[MJAVADOC-537] Explicitly the batchMode to true by @joshiste in apache/maven-javadoc-plugin#7

fix mailing list url in README by @rgdoliveira in apache/maven-javadoc-plugin#13

[MJAVADOC-544] - Changed behaviour of Javadoc for temporary files encoding (options, argfile, ...) by @michael-st in apache/maven-javadoc-plugin#10

[MJAVADOC-444] add aggregate-no-fork and aggregate-test-no-fork for non-forking versions of aggregate goals. by @busbey in apache/maven-javadoc-plugin#2

Avoid converting separator characters into newline. by @cowwoc in apache/maven-javadoc-plugin#19

[MJAVADOC-577] Fixed typos in User Guide. by @glqdlt in apache/maven-javadoc-plugin#20

Fix typo in additionalDependencies documentation by @britter in apache/maven-javadoc-plugin#23

Add missing @since tags to sourceFile[Includes|Excludes] by @britter in apache/maven-javadoc-plugin#24

Added example of --add-modules to aggregate FAQ. by @cowwoc in apache/maven-javadoc-plugin#18

Remove space typo in markdown by @nrbw in apache/maven-javadoc-plugin#29

[MJAVADOC-620] Do not ignore JARs w/o module info when building classpath by @fwienber in apache/maven-javadoc-plugin#35

[MJAVADOC-626] Add a stale javadoc detection mechanism by @gnodet in apache/maven-javadoc-plugin#33

[MJAVADOC-613] exclude skipped modules from javadoc aggregate by @olamy in apache/maven-javadoc-plugin#36

[MJAVADOC-636] exclude some modules from aggregated javadoc by @olamy in apache/maven-javadoc-plugin#37

[MJAVADOC-639] include requires static from external dependencies for all modules by @olamy in apache/maven-javadoc-plugin#38

[MJAVADOC-638] upgrade Doxia Sitetools to 1.9.2 to remove dependency on Struts by @olamy in apache/maven-javadoc-plugin#39

MJAVADOC-610 by @olamy in apache/maven-javadoc-plugin#40

... (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 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
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
BXMSDOC-8220 Vaccination Scheduler

We are using this PR to figure out all of the components that we need to single-source OptaPlanner content. Details are in BXMSDOC-8220.

The HTML draft is here.

opened by emmurphy1 1

Optaplanner

Related tags

Overview

OptaPlanner

Looking for Quickstarts?

Quick development start

Starter issues

Developing Drools, OptaPlanner and jBPM

Code style

Definition of Done

Comments

JIRA

Referenced pull requests

JIRA

Referenced pull requests

Checklist

CI Status

JIRA

Referenced pull requests

Checklist

JIRA

JIRA

JIRA

Referenced pull requests

Checklist

CI Status

JIRA

Referenced pull requests

Checklist

CI Status

3.4.1

📦 Dependency updates

3.4.0

What's Changed

3.3.2

What's Changed

CI Status

Owner

KIE (Drools, OptaPlanner and jBPM)