Build/launch doesn't complete if no internet access

[kriegfrj]

Scenario:

• I am not connected to the internet.
• I open a Bndtools workspace in Eclipse.
• Eclipse starts trying to rebuild the workspace, but gets stuck indefinitely in the "refresh repositories" phase.
• Similar issues when trying to launch

If you switch it into "offline" mode it works, so there is at least a workaround. However, it would be better if the build could fail more gracefully, or else perhaps give up trying to download artifacts when there is no internet connection rather than retrying indefinitely.

I feel like this is a fairly recent regression. I don't recall Bnd always behaving in this way.

[chrisrueger]

I tried reproducing naively by disabling WiFi and open eclipse with the bnd workspace, but everything worked fine.

Do you have any more ideas or details about your setup?

In Slack recently there was a problem I guess with the bnd workspace and the bnd m2e Eclipse plugin and some sort of hanging. Mentioning it just in case.

[kriegfrj]

Setup:

• Windows 11 (maybe this makes a difference to the way that network connectivity is interpreted by Eclipse/Bnd/Bndtools?)
• Eclipse not running.
• Wifi on on my laptop but not connected to any network, and no wired ethernet connection. I also have a Wireshark VPN installed but I double-checked that it is currently not running.

Steps:

• Start Eclipse, open my workspace, which is a Bndtools workspace (ie, not Maven or Gradle)
• The "Load Repositories" phase of setup takes a very long time. As you can see from this video, it seems to be attempting to download artifacts from Maven. These artifacts are accessed via a MavenBndRepository, and they should all already be cached locally on my machine as this is not the first time I have started this workspace. So I think MavenBndRepository is trying to do a HEAD to see if the locally cached copy is up-to-date:

idempiere-plugins-workspace.-.Eclipse.IDE.2025-09-25.10-19-16.mp4

• Once "Load Repositories" finishes, Eclipse attempts to rebuild the workspace. This time it is the JavaBuilder that is very slow:

idempiere-plugins-workspace.-.Eclipse.IDE.2025-09-25.10-17-26.mp4

Again, you can see it is trying to download artifacts. As it is the JavaBuilder running, I suspect the slow part of the code path is the attempt to resolve the Bnd Bundle Path container in the project, which in turn attempts to access the Repository implementations that back them, which in turn causes them to an up-to-date check via the network. (Normally, the build of org.opensaml is very fast.)

The issues with launching are likely related - the launcher attempts to load the sources for source lookup implementation, and again this would require accessing the repositories.

[kriegfrj]

I should add, if you switch Bndtools into "offline" mode (the little powerplug toolbar button at the top of the Repositories view), all of these problems disappear. So there's an easy workaround, and probably not a big priority to fix. I just don't recall it being an issue before (though that could just be a memory failure on my part), so perhaps something has changed in the repository refreshing code recently that triggers this behaviour.

[chrisrueger]

I assume we are talking about latest 7.2.0 SNAPSHOT, right?

so perhaps something has changed in the repository refreshing code recently that triggers this behaviour.

I remember that in 6bc0140 I was touching something related to "refresh".
I checked a few more things, but e.g. bnd's HTTPClient.java has not been touched for a long time.

As I am on MacOS I asked ChatGPT for a few clues of Windows vs MacOS differences regarding networking (as usual not sure how much AI halucination is involved, but maybe it helps. I shortened the answers a bit):

Proxy auto-detection (WPAD) & “Native” proxy provider
On Windows, Eclipse’s “Native” proxy provider will consult OS proxy settings. If WPAD/Auto-detect is enabled, Windows probes special hostnames (e.g., wpad.domain) and/or DHCP for a PAC file. With no network, those probes can stall for a long time, repeatedly timing out before the HTTP stack gives up. macOS systems tend to fail-fast in truly offline states

IPv6 vs IPv4 fallback (“Happy Eyeballs”) differences
run Eclipse with -Djava.net.preferIPv4Stack=true (or disable IPv6) to see if the hang disappears.

Windows DNS & WPAD lookups when offline
Beyond proxies, Windows DNS search-suffix probing and NetBIOS/LLMNR attempts can add long delays when there’s no working resolver.

File-locking/IPC quirks on Windows (secondary contributor)
Not the main cause here, but worth noting: Maven Resolver documents OS-specific workarounds for Windows file locking, which can aggravate “refresh repos” if another Eclipse/daemon process left lock files behind. If you see “refresh repositories” stuck even when online, wipe stale locks or tweak the Resolver’s named-file-lock settings.
Check for stale locks in your Bnd workspace cnf/cache or repo caches if hangs persist even online; clean/restart (ties to Windows file-locking quirk
see the setting "aether.named.file-lock.deleteLockFiles" on https://maven.apache.org/resolver/configuration.html links to https://bugs.openjdk.org/browse/JDK-8252883

Maybe @peterkir has more ideas, as he is also uses bndtools with windows sometimes.

In any case, if we find out that it is windows related, we should add it here