- notifications - lists.xwiki.org

[[email protected]][Issue] Updates for XWIKI-24741: Provide a localization adapter for ES modules
by XWiki Notifications 26 Aug '26

26 Aug '26

1 0

[xwiki/xwiki-platform]
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/misc-sonar-regex-backtracking Home: https://github.com/xwiki/xwiki-platform To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-platform] 1cbbd1: [Misc] Simplify two regular expressions that backt...
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 1cbbd138c1d0aa39dc0ba384b54340a6d18efb42 https://github.com/xwiki/xwiki-platform/commit/1cbbd138c1d0aa39dc0ba384b543… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M xwiki-platform-core/xwiki-platform-csrf/src/test/java/org/xwiki/csrf/DefaultCSRFTokenTest.java M xwiki-platform-tools/xwiki-platform-tool-standards-validator/src/main/java/org/xwiki/validator/HTML5DutchWebGuidelinesValidator.java Log Message: ----------- [Misc] Simplify two regular expressions that backtrack super-linearly (SonarQube) (#6232) * java:S8786: the CSRF token check matched ".*[bad chars].*" against the whole token, and the email pattern of the Dutch web guidelines validator chained two unbounded quantifiers over overlapping character sets ("([\.\w])+[\w]+"). Both backtrack quadratically on a non-matching input. The token check now looks for the bad characters with find() instead of wrapping them in ".*", and the local part of the email is matched by "[\w-][.\w]+\w", which accepts exactly the same strings. * java:S5998: the domain part "([\w-]+\.)+" is a group repetition, which Java's regex engine implements recursively and can therefore overflow the stack on a long input. Making the group atomic keeps the same language while letting each iteration leave no backtracking state behind. Co-authored-by: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-docker] ac23fd: XDOCKER-18: Automate updating the stable version
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/XDOCKER-18-automate-docker-images-release Home: https://github.com/xwiki/xwiki-docker Commit: ac23fd7bc43d1e1e74e83898f8602973242b1ad8 https://github.com/xwiki/xwiki-docker/commit/ac23fd7bc43d1e1e74e83898f86029… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M README.md M build.gradle M gradle/helpers.gradle M gradle/official-image.gradle M gradle/run-instances.gradle M gradle/update-versions.gradle Log Message: ----------- XDOCKER-18: Automate updating the stable version * Regenerate the images in 'submitOfficialImage', so that a 'versions.json' pushed without its regenerated directories is reported as a dirty tree instead of publishing tags the pushed Dockerfiles do not produce. * Refuse in 'updateXWiki' a bump that would put two cycles on the same version line, which the duplicate tag check rejects at configuration time and would therefore leave every later './gradlew' failing. * Boot in 'smokeTest' the cycles 'generate' rewrote as well as the ones whose versions moved, so that a 'template/' edit is smoke-tested by 'release' too. * Add '-Pfresh' to 'runAll', to remove each instance and its volumes before starting it. * Validate the boolean command line flags, '-PdryRun=false' having read as true. * Drop a comment justifying itself by an earlier revision, and a transient issue key from another. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-docker/settings/notifications

1 0

[[email protected]][Issue] Updates for XWIKI-24732: The fact that the page titles can be changed in edit mode is not so visible anymore
by XWiki Notifications 26 Aug '26

26 Aug '26

1 0

[xwiki/xwiki-platform] ab8eb4: [Misc] Simplify two regular expressions that backt...
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/misc-sonar-regex-backtracking Home: https://github.com/xwiki/xwiki-platform Commit: ab8eb4d711579475f81cf26c77db05b0d91decae https://github.com/xwiki/xwiki-platform/commit/ab8eb4d711579475f81cf26c77db… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M xwiki-platform-core/xwiki-platform-csrf/src/test/java/org/xwiki/csrf/DefaultCSRFTokenTest.java M xwiki-platform-tools/xwiki-platform-tool-standards-validator/src/main/java/org/xwiki/validator/HTML5DutchWebGuidelinesValidator.java Log Message: ----------- [Misc] Simplify two regular expressions that backtrack super-linearly (SonarQube) * java:S8786: the CSRF token check matched ".*[bad chars].*" against the whole token, and the email pattern of the Dutch web guidelines validator chained two unbounded quantifiers over overlapping character sets ("([\.\w])+[\w]+"). Both backtrack quadratically on a non-matching input. The token check now looks for the bad characters with find() instead of wrapping them in ".*", and the local part of the email is matched by "[\w-][.\w]+\w", which accepts exactly the same strings. * java:S5998: the domain part "([\w-]+\.)+" is a group repetition, which Java's regex engine implements recursively and can therefore overflow the stack on a long input. Making the group atomic keeps the same language while letting each iteration leave no backtracking state behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[[email protected]][Issue] Updates for XWIKI-22257: Hash the superadmin password
by XWiki Notifications 26 Aug '26

26 Aug '26

1 0

[xwiki/xwiki-platform] 1696a6: XWIKI-24710: Add script APIs to count distinct act...
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/XWIKI-24710 Home: https://github.com/xwiki/xwiki-platform Commit: 1696a6109516445d562e7f92661d0e53db1047dd https://github.com/xwiki/xwiki-platform/commit/1696a6109516445d562e7f92661d… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/pom.xml M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/ActiveInstallsConfiguration.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/DataManager.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/internal/DefaultActiveInstallsConfiguration.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/internal/DefaultDataManager.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/script/ActiveInstallsScriptService.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/test/it/org/xwiki/activeinstalls2/internal/PingSenderIT.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/test/java/org/xwiki/activeinstalls2/ActiveInstallsConfigurationTest.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/test/java/org/xwiki/activeinstalls2/internal/DefaultActiveInstallsConfigurationTest.java M xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/test/java/org/xwiki/activeinstalls2/script/ActiveInstallsScriptServiceTest.java M xwiki-platform-tools/xwiki-platform-tool-configuration-resources/src/main/resources/xwiki.properties.vm Log Message: ----------- XWIKI-24710: Add script APIs to count distinct active installs globally and per extension * Make the per-extension cardinality precision threshold configurable through the new activeinstalls2.extensionInstanceCountPrecisionThreshold property, so that the counts of the most widely installed extensions can be kept exact as the install base grows without waiting for a release. The global count keeps the hardcoded 40000, which is the maximum Elasticsearch supports. * Clamp both configured values in DefaultDataManager rather than only in DefaultActiveInstallsConfiguration, since any implementation of the ActiveInstallsConfiguration role can be injected there and an out-of-range value would overflow the over-request or be rejected by Elasticsearch. * Return a SequencedMap from countDistinctInstallsByExtension(), so that the documented bucket ordering is part of the type rather than only of the Javadoc. * Drop TooManyExtensionsException from the throws clauses, where it is redundant with the Exception it extends, and document it with @throws instead. * Share the wrapper-query construction between countInstalls() and the search requests. * Document the query restricting a count to the instances that are actually active on the DataManager methods, which counted over the whole index otherwise. * Document both ends of the maxExtensionCountPerQuery clamping in xwiki.properties. * Split the phase invalidating the single-instance fixture out of PingSenderIT#sendPingData() into its own @Order(2) test, so that the dependency between the two is enforced rather than only commented. * Raise the non-integration-tests instruction ratio from 0.11 to 0.12, the module now being at 0.12394 without the IT and 0.9256 with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-docker] 4f9836: XDOCKER-18: Automate updating the stable version
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/XDOCKER-18-automate-docker-images-release Home: https://github.com/xwiki/xwiki-docker Commit: 4f98360bf634919b588bcd62b05d4d8e70523f98 https://github.com/xwiki/xwiki-docker/commit/4f98360bf634919b588bcd62b05d4d… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M README.md M gradle/helpers.gradle M gradle/official-image.gradle M gradle/run-instances.gradle Log Message: ----------- XDOCKER-18: Automate updating the stable version * Default 'stream' to running in the project directory, as 'capture' and 'exitCode' already do. A process inherits the working directory of the JVM that starts it, which for a Gradle build is the daemon's and therefore not something a script gets to assume. Every command run through it passes one today, so this only ever matters for the next one written without. * Validate the '-Pcycles' and '-Pvariants' entries against the cycles and variants that exist, the way '-PbasePort' and '-PtargetRepo' already validate theirs. Both ways of getting them wrong were silent: an empty value ('-Pcycles' with nothing after it) left an empty list, which every caller reads as "no selection" and therefore as "all of them" - the opposite of narrowing anything down - and a typo such as '-Pvariants=mysql' surfaced only later as a missing directory, naming a path rather than the property that named it. The message lists the available values, which is what whoever got it wrong is looking for. * Establish the submission guards before '-PdryRun' returns rather than after it. "Am I ready to submit?" is what a dry run is reached for, and answering only "here is what the file would look like" left the release manager to discover a dirty tree, an unpushed HEAD or a red Docker Build run on the real invocation instead. A dry run reports them and still succeeds where a real one fails on them, since the natural moment to preview the file is right after './gradlew release', with the regenerated tree not yet committed. * Collect those reasons instead of throwing on the first, so that one run names everything that is in the way. 'checkImagesBuild' returns its reason rather than raising it, for the same purpose. * Check for a Pull Request still open from the working branch in a rehearsal too. Unlike the guards on what is reachable upstream, that one is about not destroying something on the target, which a target of your own has just as much of. * Say in the Docker Build check why looking at the most recent runs alone is enough for the two questions it asks. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-docker/settings/notifications

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 26 Aug '26

26 Aug '26

Branch: refs/heads/claude/cool-tesla-ssthkt Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0