Skip to content

update master branch#1

Merged
mayerro merged 35 commits into
dbeaver:masterfrom
eclipse-equinox:master
May 11, 2026
Merged

update master branch#1
mayerro merged 35 commits into
dbeaver:masterfrom
eclipse-equinox:master

Conversation

@mayerro
Copy link
Copy Markdown
Member

@mayerro mayerro commented May 11, 2026

No description provided.

laeubi and others added 30 commits March 2, 2026 06:29
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 6 to 7.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](actions/upload-artifact@v6...v7)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [json](https://github.com/ruby/json) from 2.18.1 to 2.19.2.
- [Release notes](https://github.com/ruby/json/releases)
- [Changelog](https://github.com/ruby/json/blob/master/CHANGES.md)
- [Commits](ruby/json@v2.18.1...v2.19.2)

---
updated-dependencies:
- dependency-name: json
  dependency-version: 2.19.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Some callers of SLF4J log null messages which OSGi Logger does not allow.

Fixes: #1253
Does not cause exception but does cause unexpected behaviour

Issue #1253
Correct enabled check & fix to log as error not info

Issue #1253
Async framework event may still be getting delivered and we
need to make sure no pending events are waiting to be logged
before adding the test listener; otherwise timing issues could
happen with unexpected logs for the pending events from starting
the framework.
o.e.equinox.supplement"

This reverts commit e50ec5f.
Bumps [activesupport](https://github.com/rails/rails) from 8.0.2 to 8.0.4.1.
- [Release notes](https://github.com/rails/rails/releases)
- [Changelog](https://github.com/rails/rails/blob/v8.1.3/activesupport/CHANGELOG.md)
- [Commits](rails/rails@v8.0.2...v8.0.4.1)

---
updated-dependencies:
- dependency-name: activesupport
  dependency-version: 8.0.4.1
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [emibcn/badge-action](https://github.com/emibcn/badge-action) from 2.0.3 to 2.0.4.
- [Release notes](https://github.com/emibcn/badge-action/releases)
- [Commits](emibcn/badge-action@808173d...f9150fd)

---
updated-dependencies:
- dependency-name: emibcn/badge-action
  dependency-version: 2.0.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [addressable](https://github.com/sporkmonger/addressable) from 2.8.7 to 2.9.0.
- [Changelog](https://github.com/sporkmonger/addressable/blob/main/CHANGELOG.md)
- [Commits](sporkmonger/addressable@addressable-2.8.7...addressable-2.9.0)

---
updated-dependencies:
- dependency-name: addressable
  dependency-version: 2.9.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Also build launcher binaries for macOS on agents of the targeted
architecture.
With recent changes, the macOS native launcher binaries are built on the
Jenkins agents with the fitting architecture. This includes the usage of
different macOS SDKs. For the x86 build, a macOS 15 SDK is used, whereas
the aarch64 build uses a macOS 26 SDK. After that change, the behavior
of applications using the binaries built with macOS 26 SDK show
significantly changes behavior and appearance (such as title bar text
alignment, background colors, invisible lists and the like), rendering
applications hardly usable or even partly unusable.

With this change, the binaries are always built on the x86 agent, which
runs macOS 15 and uses the according SDK, to restore existing behavior.
This is supposed to be a temporary solution until the Eclipse Platform
has been updated to be compatible with the macOS 26 SDK behavior.
Avoids using the same ServiceLoader instance from muiltiple
threads.  ServiceLoader instances are not thread-safe.
Use different protocol/content-type each iteration to
make sure the handler factory is called each iteration.
The ServiceLoader usage is incorrectly looking up URLStreamHandlerFactory.
The java.net.spi.URLStreamHandlerProvider was added in Java 9.
We could decide to lookup providers instead, but at this time
it seems unnecessary because the JVM will do this if we return
null.

In the future we can decide if providers should be called by Plurl,
but that seems an unnecessary complication.

The ContentHandlerFactory ServiceLoader usage remains necessary
because we must not return null from the Plurl factory for
ContentHandlerFactory.
@mayerro mayerro merged commit 1b6e9e7 into dbeaver:master May 11, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants