Proximity allows configuring which remote repos to automatically download from - including none, enabling manual only. However I don't know about limiting it to one user.
I think you need to ask Tamás Cservenák (Proximity author) on the privs capability. He will tell you to post on the Proximity support forum... -----Original Message----- From: Lakshman Srilakshmanan [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:34 PM To: [EMAIL PROTECTED] Cc: Maven Users List Subject: RE: [m2] copy of Central Repository Hi Jeff, I am sorry I did not understand your original mail. Further reading confirms that Proximity is what I am looking for. Could you please clarify one question before I charge down this path ? I actually control the internal.central repository. I don't allow developers to pollute the internal.central repository with any version of the software they want. Before the internal.central repository is upgraded we get a consensus from the development team. This ensures that we don't get any library conflicts. I controlled this in maven.1.x by ensuring that the internal.central repository was owned by "xxx" and "xxx"'s localRepository was pointing to internal.central. This ensured that only "xxx" could place libraries into the repository and all the developers would get an error if the library did not exist. My initial reading of Proximity indicates that it will download from repo1.maven.org (or from where ever) _automatically_ when it can't find the library in internal.central. Is there a way of controlling this. Would I be able to control who can _automatically_ populate internal.central and give an error to the others ? Thanks again for you assistance in this issue. Thanks Lakshman > -----Original Message----- > From: Jeff Jensen [mailto:[EMAIL PROTECTED] > Sent: Friday, 25 August 2006 10:24 PM > To: 'Maven Users List' > Subject: RE: [m2] copy of Central Repository > > That's fine, these products allow manual installation as well (in fact, they > expect you to). This handles the use cases of using commercial artifacts > (Oracle, MQ Series, and Java itself, etc.) and installing artifacts from > your own company's products. > > By your statement, I wonder if you misunderstand how they are used/what they > do. FYI, We use Proximity; it works great. I suggest reading its docs/site > info. > > > -----Original Message----- > From: Lakshman Srilakshmanan > [mailto:[EMAIL PROTECTED] > Sent: Friday, August 25, 2006 3:20 AM > To: Maven Users List > Cc: [EMAIL PROTECTED] > Subject: RE: [m2] copy of Central Repository > > Hi > > We can't do this because from time to time we may need to download files > manually and install it. > > Thanks > Lakshman > > > > -----Original Message----- > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet > > Sent: Friday, 25 August 2006 5:57 PM > > To: [email protected] > > Subject: Re: [m2] copy of Central Repository > > > > Putting up a maven proxy might solve your problem: > > the first time a jar is needed it downloads it from the central repo > and > > caches it. > > > > There are 3 free implementations I know of: > > maven-proxy (from the maven guys): beta?, abandoned in favor of > Archiva > > Archiva (from the maven guys): beta, needs to be build from source, > but > > has some positive remarks on this list Proximity (from 3th party): > > sounds more stable, has had a bunch of releases and some positive > > remarks on this list > > > > Check this list for "Archiva" and "proximity". > > > > Lakshman Srilakshmanan wrote, On 2006-08-25 8:53 AM: > > > Hi All, > > > > > > In maven 1.x I could execute maven once on a project and build my > local > > > repository. I could then copy it on to my company's central server > and > > > get all the developers to refer to this for updates. > > > > > > When I needed a new plugin or dependency, I could run maven 1.x > against > > > ibiblio and follow the above process. > > > > > > The above strategy ensured that we had only the plugins & > dependencies > > > we needed and not the whole central repository of 5G. I am not going > > > into the details of how I kept this up-to-date as it would side > track > > > the main issue that I wish to discuss. > > > > > > > > > Now, in maven 2 I did the same process as described above. The build > > > started breaking, with errors such as -- plugin 'xxx' does not exist > or > > > no valid version could be found --. > > > > > > Further investigation revealed this problem was due to two missing > files > > > in my repository. > > > a) maven-metadata.xml > > > b) maven-metadata.xml.sha1 > > > > > > In my local repository these files are named as > > > a) maven-metadata-central.xml > > > b) maven-metadata-central.xml.sha1 > > > > > > so when I copied my local repository to my company's central > repository > > > the above files caused the problem. > > > > > > When I renamed the files as required, maven 2 was happy and > everything > > > started to work again. > > > > > > > > > So my question is, is there a easier way of getting the required > > > components from maven central repository copied to my company's > central > > > server without having to take a full copy ? > > > > > > Well, an alternative is to create a script to traverse the > repository > > > and rename the files as required. > > > > > > I would much appreciate to hear from anyone who has solved this > problem > > > or is there a tool/process that I have overlooked. > > > > > > Thanks in advance > > > > > > Lakshman > > > > -- > > With kind regards, > > Geoffrey De Smet > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
