On 8/31/06, ArneD <[EMAIL PROTECTED] > wrote:
... Afterwards you can disconnect the proxy from Internet, or use the proxy's cache as your internal plugin repository. (Keeping the proxy alive and connected to the Internet might be unacceptable because you want to evaluate new plugins before you release them for internal usage.)
Why people think that some software can solve this autonomously? You will anyway do some internal "company- wide" staging for plugin evaluation/JAR introspection/ etc. So have a man put on this job and let he "filter" out the unwanted stuff. Keep inhouse repo server unplugged, you don't have to leave proxy "plugged in". When I wanted to use Maven-proxy for this purpose, I soon encountered
problems because it did not support NTLM authentication, so I could not get through the firewall. So we helped us with zipping up a local repo as a workaround.
Firewall or proxy? All OSS based software will support NTLM as much as they can without PAYING for specs. Proximity relies on Jakarta HttpClient, so it supports NTLM v1, but not NTLM v2. Anyway, you can still enable DIGEST or BASIC auth on those nasty M$ proxies to work in paralell with NTLM. Actually, IIS setup by default enables NTLM, DIGEST and BASIC auths per default, in this order. Here, you can force Proximity to use DIGEST or BASIC. Anyway, I think that the whole task of setting up an internal plugin
repository is too complicated. We don't want to use a proxy, so why do we have to set it up.
Right. Take Proximity for example, since it is not JUST proxy. If you visit the demo site, you will see that proximity is able to PROXY repositories but also to HOST them only. Furthermore, you can just "take offline" (offline == do not touch remote peer!) or "take unavailable" (unavailable == refuse all requests) a repo from proximity by a switch. Why is it better then hosting inhouse repo with plain Apache HTTPD? Well, you have powerful artifact search, you have AccessManager, control over availability per repository (and not per HTTPD server).... etc. --- And for Xerces example: IF you have a developer who declares an obiously existing (it's in repo downloaded from plugn repo) artifact which is obviously "forbidden" (it is not in company repo), than you have a HR problem. No software will ever overcome human stupidity. Nor IT rigidness. ~t~
