cstamas wrote: > > 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. >
I agree, Proximity is promising, and I will definitely take a further look. I first heard about it after initially setting up the Maven build environment. Eric's question was, what is people preventing from using Maven. The points that I named did not prevent me from using Maven, neither from recommending its usage. I just want to point out things that corporate users are concerned of. All these things are solveable. The question is, how much do you get out-of-the-box and how easy is it to use. > 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. > The reality in many companies is that you have people with very different skills and experiences in IT departments. The idea of build automation is not only to make life simpler, but also to help people to avoid mistakes. Build automation should be easy-to-use for people even who use it the first time. So, in the Xerces example, one might just not be aware of the fact that Xerces is not in the company repository, but only in the plugin repository. Regards, Arne -- View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6088427 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
