It’s a known issue based on how Java handles a leading slash on Windows. There’s a ticket in for it, but I’m on my phone so I can’t find it ATM.
Why would a package have an installation directory outside the main package anyway though? I don’t that’s even supported. I think I force that to be relative. I’ll check the docs/code when I get home.
Happy Connecting. Sent from my Sprint Samsung Galaxy S® 5
Why would a package have an installation directory outside the main package anyway though?
I was afraid you were going to ask that. I was just playing around with dependencies and wanted to see what would happen if I mixed package types. (CommandBox commands with other package types, etc) 
Right here in the docs…
https://ortus.gitbooks.io/commandbox-documentation/content/packages/boxjson/installation.html
The directory property is forced to be relative to the web root. And here’s the corresponding code. You can see I strip any leading slashes off.
The CommandBox commands package type is deprecated in favor of Commandbox-modules. When a CommandBox module is installed, the working directory is overridden to be the root of the CFML folder inside the CommandBox installation so everything will be relative to that. You can have a CommandBox module that depends on another module (commandbox or not) and it should be installed alongside the CommandBox “user” modules folder. Any “vanilla” packages would just get dumped in the CFML dir.
And regarding that behavior of leading slashes on Windows, here’s the ticket. Feel free to take a stab at it. We’d have to add some logic to the fileSystemUtil’s resolvePath() method when the local OS is Windows to work differently. Right now it uses the java.io.File class’s isAbsolute() method which returns false for paths that start with a leading slash on Windows.
Thanks!
~Brad
ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com