> Especially in large companies, it is often unacceptable to let users > download artefacts directly from an Internet repository, even not through a > proxy.
I agree wholeheartedly - this was one of our biggest stumbling blocks and one of the reasons we opted NOT to use a proxy and simply have an internal remote repository. Security was afraid of "man in the middle" type attacks. Additionally, I'll have to eventually move these artifacts off their current server to another one. Since this is a production build system tool, I'll be unable to run http as the fileserver these artifacts will reside on won't have apache/iis and support won't allow any webserver to be installed. This machine also has zero internet visibility. > Companies need to have full control over all artifacts used in their > build processes, that means that only artefacts that have been explicitly > released by someone should be used. So when you start using Maven, you want > to immediately set up an internal repository which, I believe, is still a > too complicated task. I agree on this point too. There isn't much saying how exactly to do this and when you're starting from scratch for a project that has already been using repo1 for a month, this can be a massive undertaking. I found a chunk of an ant script that renames the metadata files and added the functionality to generate the md5 and sha1 key files. What this allows you to do is work as if you have no internal repository, then simply move everything across to another machine (and run this script there) - then you're in business. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
