Hi EJ, I encountered the same problem with plugins hosted on an internal repository recently and resolved it using the ant script suggested at this page:
http://www.nabble.com/Re%3A-Internal-%28intranet%29-repositories-p3876819.html Regards, Rod On 7/13/06, Tamás Cservenák <[EMAIL PROTECTED]> wrote:
Just to make myself clear: I think you need INHOUSE repository. It is (in my definition) a remote repository (from the aspect of developer) but housed and server on your company intranet in a controlled manner. Proximity is highly configurable, actually it only offers some buildingblocks (repository, remotePeer, localStorage, etc) and one "proposal" for a common user. If you look at configuration reference (yes, i know, it's uncomplete) here http://proximity.abstracthorizon.org/configuration.html it shows actually a "factory default" configuration. rules are simple: One proximity bean - MANDATORY, the Proximity Application itself, it can have 0..n defined repositories 0..n beans for repositories - the repositories that represents "logical" reposes. Repos have two MAIN props: a localStorage and remotePeer. There are two kinf of local storages: readOnlyLocalStorage and writeableLocalStorage. IF repos have no remote peer, it will act as a "inhouse"/end-point/(like ibiblio central) repository (will have no ability to "reach out" somewhere to pick somthing up) IF repos have no localStorage, it have no locally stored artifacts. Possible combinations with Proximity: RP = remote peer LS = local storage, ROLS = read only local storage, WRLS = writeable local storage Have RP Does not have RP No LS non-caching proxy possible but nonsense have 0 content ROLS non-caching proxy inhouse repository with local static content with local static content you may intentionally spoof this way! WRLS real caching proxy inhouse repository but write will be never be used on WRLS And remember, all combination is possible, but not all of them makes sense. And Proximity will behave as it is "wired" up, as written in this table. So nothing more than an edit of XML and restart! And you can have 0..m repositories, the proximity bean just "aggregates" these repositories. A RC2 will contain a new "feature" called repository relocation. Using this feature, you will be able to give prefixes to repositories, thus eg. server Maven1 and Maven2 repository using single instance of Proximity. For example: Current, RC1 Proximity serves repository here (default deployment on Tomcat on localhost): http://localhost:8080/px-webapp/repository/ so you have to direct Maven1 or Maven2 (Proximity does not makes difference and serves both well!) to use that URL as remote repository (using mirror in settings.xml for M2). And all defined repositories are "aggregated" on this URL. But with relocation, you will be able to define caching-proxy repository for central and codehaus on prefix /maven2 and one caching-proxy repos for http://www.ibiblio.org/maven with prefix /maven1. So, you will have to instruct Maven1 to use http://localhost:8080/px-webapp/repository/maven1 and Maven2 to use http://localhost:8080/px-webapp/repository/maven2 URLs.... and one instance of Proximity :) Have fun! Bye, ~t~ On 7/13/06, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > We don't find proximity an acceptable solution. > > Our security department frowns on anything that just grabs anything over > the internet like this. > > Their fear is someone could spoof a url (happens) and people would > download malicious code. > > Anyone else? >
