Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: In my Win32 environment I have ccm.home="C:\Program Files\eclipse\workspace\ccm-core-6.1.0.AUTO.12.13.2003-2\core". The function getConfigURL() of com.arsdigita.packaging.ConfigRegistry returns an invalid URL using this ccm home. The URL looks for the file using FTP from host "C". According to the url primer pointed to from Sun's URL JavaDoc ("http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url- primer.html") file:// uses the ftp protocal and not the local file system. Changing the URL to "file:/" works. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Try and load the config file from a Win32 system Additional info:
Changing the URL to file:/ breaks ConfigRegistry on Linux. file:// should be correct because System.getProperty("ccm.home") returns a value that has a prefix slash, which translates the URL to file:///, which translates into the file protocol.
Yes, System.getProperty("ccm.home") returns a value that has a prefix slash if you are running under a unix system but if you are running under Win32 it's going to be [Drive]:\path\to\ccm\home. So under windows the URL is file://[Drive]:\path\to\ccm\home which gets translated to get using FTP from server [Drive] the file "\path\to\ccm\home". Also what happens on unix if ccm home is not an absolute path but relative to the working directory? My guess is that it will break.
I just tested file:///[Drive]:\path\to\ccm\home and it works as well. The solution looks like ccm.home has to be the full path location and if it doesn't start with "/" add it.
Good catch. The fix appears to make the Windows ccm-run script set ccm.home with the full path.
I checked in a fix to ConfigRegistry. Unfortunately, I don't have access to a Windows box at the moment. Please let me know if the fix works for you.