maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tamás Cservenák" <>
Subject Re: [POLL] Why switch to Maven?
Date Thu, 31 Aug 2006 20:49:52 GMT
On 8/31/06, ArneD < > 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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message