如何定位导致incubator-netbeans Ant构建失败的外部文件？

I’ve been hitting an Ant build failure while setting up the incubator-netbeans project on my Ubuntu 18.04 machine. The issue boils down to a hash mismatch for the jhall-2.0_05.jar file: the build expects a SHA-1 hash of CA70822C47A67FC3A11670270567C2D01566DAE1, but the downloaded file has a hash of DA39A3EE5E6B4B0D3255BFEF95601890AFD80709—which is actually the SHA-1 of an empty file, meaning the download didn’t complete correctly or the file was replaced somewhere in the process.

I’ve already tried deleting the entire source directory and re-cloning the repo, but the problem persists. Oddly enough, this doesn’t happen on CI services, Docker containers, or VirtualBox images—only on my local Ubuntu 18.04 setup. I suspect some configuration file outside the source root is interfering, and I’m looking for ways to track down that file. I know the project is moving to Maven, but I want to resolve the Ant build issue directly instead of switching builds right now.

Steps to Diagnose the Root Cause #

Here are targeted troubleshooting steps to identify the external configuration or system setting causing the problem:

1. Check Global Ant Configuration Files #

Ant reads user-level and system-level config files that might alter download behavior:

• User-level: Look for ~/.ant/settings.xml or ~/.antrc—these could define custom proxies, alternative repositories, or modified download tasks that intercept the request for jhall-2.0_05.jar.
• System-level: Check /etc/ant.conf or /usr/share/ant/etc/ant.conf for similar network-related overrides.

2. Audit System-Wide Network Interceptions #

Ubuntu 18.04 might have tools that block or redirect download requests:

• Proxy Settings: Run echo $http_proxy $https_proxy $HTTP_PROXY $HTTPS_PROXY to check for active proxies. Try temporarily unsetting them (unset http_proxy https_proxy) and re-running the build.
• Firewall/Security Tools: Verify if ufw, iptables, or third-party security software is interfering. You can temporarily disable ufw with sudo ufw disable (remember to re-enable it later) to test.
• Manual Download Test: Grab the jar directly with wget https://archive.apache.org/dist/javahelp/jhall-2.0_05.jar, then run sha1sum jhall-2.0_05.jar to check the hash. If the hash is still wrong, your network is redirecting the download. If it’s correct, the issue is specific to Ant’s execution environment.

3. Clear Ant’s Download Cache #

Ant caches downloaded binaries, so even deleting the source repo won’t remove cached (and corrupted) files:

• The default cache directory is usually ~/.ant/cache. Delete it entirely with rm -rf ~/.ant/cache, then re-run ant to force a fresh download.

4. Inspect Hosts File and DNS Settings #

A modified hosts file or misconfigured DNS could send download requests to the wrong server:

• Check /etc/hosts for any entries pointing to archive.apache.org—if found, comment them out with a # and save, then retry the build.
• Switch to a public DNS like 8.8.8.8 temporarily (update /etc/resolv.conf or use your network settings) to rule out DNS-related redirection.

5. Enable Ant Debug Logging #

Get granular details about the download process by running Ant in debug mode:

• Execute ant -debug and look for logs related to the downloadbinaries task. This will show you the exact URL being requested, the server response, and where the file is being saved—critical clues for pinpointing where the file is being altered.

6. Check NetBeans/Java User Configs #

If you’ve had NetBeans installed before, leftover configs might be affecting the build:

• Rename the ~/.netbeans directory (e.g., mv ~/.netbeans ~/.netbeans.bak) to isolate any cached settings or overrides.
• Run java -XshowSettings:properties to check for Java system properties that might affect network requests (like http.proxyHost or https.proxyPort).

内容的提问来源于stack exchange，提问作者Kalle Richter