Well, we actually use maven-proxy to host the inhouse repository. Basically, we have it configured with repo.local.store pointing to the actual repository dir and repo.list empty. Thus, it just serves up what's in the dir.
The main reason we did that was for the search capabilities. A developer can point at the repository URL and execute a search. Works quite well when it gets large. Keeps people from having to log into the machine and running a "find". It also means the "UI" is exactly the same for the proxied content as the non-proxied content. That said, we DO use maven-proxies at our other remote sites to proxy the inhouse repository. That's just a performance enhancement though. The VPN between the sites isn't always very good. Enjoy! Dan On Thursday 25 May 2006 18:01, Kathryn Huxtable wrote: > Of course, one answer leads to another question... ;-) > > Why bother proxying inhouse repositories? I don't see the logic there. > > -K > > On 5/25/06 4:58 PM, "Kathryn Huxtable" <[EMAIL PROTECTED]> wrote: > > In that case, I'll stick with the webapp. Thanks much! -K > > > > On 5/25/06 4:56 PM, "ben short" <[EMAIL PROTECTED]> wrote: > >> Kathryn > >> > >> The idea is to have one proxy per organisation. That way if all the > >> programmers need spring as a dependancy, the proxy only downloads it > >> once, when the first programmer tries to build their project. the > >> next programmer gets the dependancy from the proxy, making it much > >> faster. > >> > >> Ben > >> > >> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: > >>> Thanks, that worked. > >>> > >>> Is the general opinion that each developer should set up > >>> maven-proxy on their own machine, or have one proxy site for an > >>> organization? If it's on my local machine I can use standalone. > >>> > >>> -K > >>> > >>> On 5/25/06 2:36 PM, "ben short" <[EMAIL PROTECTED]> wrote: > >>>> Kathryn. > >>>> > >>>> You need to add the following to your settings.xml. > >>>> > >>>> <mirror> > >>>> <mirrorOf>central</mirrorOf> > >>>> <name>Internal Mirror</name> > >>>> <url>http://url.to.your.proxy</url> > >>>> <id>local-proxy</id> > >>>> </mirror> > >>>> > >>>> When you rum mvn on your local machine it will go to your proxy > >>>> for the plugins and dependancies it needs. If the proxy doesnt > >>>> have the requested jars it will try and get them from ibiblio, > >>>> codehaus or other remote repositries. > >>>> > >>>> Ben > >>>> > >>>> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: > >>>>> Okay, I'll bite. I just set up maven-proxy-webapp (my team > >>>>> doesn't have control over the firewall settings for our web > >>>>> servers, so I need to have this on 80/443). > >>>>> > >>>>> I copied a maven-proxy-config.properties file from somewhere and > >>>>> edited the > >>>>> WEB_ROOT to be my local locations. > >>>>> > >>>>> What now? > >>>>> > >>>>> What do I change in settings.xml and pom.xml to make this work? > >>>>> > >>>>> And how do I populate the proxy with jars so that the next time > >>>>> codehaus or > >>>>> ibiblio is down I can get work done? > >>>>> > >>>>> -K > >>>>> > >>>>> On 5/25/06 11:51 AM, "dan tran" <[EMAIL PROTECTED]> wrote: > >>>>>> Chas, i feel your pains, so here a list of my own > >>>>>> recommendations: > >>>>>> > >>>>>> 1. Get a maven-proxy in place, so when a central repo is > >>>>>> down, you can switch to > >>>>>> a another mirror without user notice. Set up maven-proxy > >>>>>> is not that > >>>>>> hard ;-) > >>>>>> check out archive list for all maven-proxy discussion. > >>>>>> Feel free to > >>>>>> ping us for help > >>>>>> > >>>>>> 2. Dont use snapshot, cut a release yourself. I fetch the > >>>>>> source and post fix the version > >>>>>> with svn revision number. For example, if I need a > >>>>>> feature/bug fix > >>>>>> in maven-assembly-plugin > >>>>>> version 2.2-snapshot, then I build 2.2-${svn.revision} > >>>>>> and deploy to > >>>>>> your > >>>>>> internal repository that can serve by maven-proxy. > >>>>>> > >>>>>> 3. Use pluginManagement to specify all plugins that used by > >>>>>> your project'poms. > >>>>>> This get your team's build much faster since it does not > >>>>>> have to go > >>>>>> to maven-proxy to look > >>>>>> for daily update. > >>>>>> > >>>>>> This settup will prevent most of maven's uncertainties that > >>>>>> others and I have gone thru > >>>>>> > >>>>>> Hope it helps > >>>>>> > >>>>>> -D > >>>>>> > >>>>>> On 5/25/06, Chas Douglass <[EMAIL PROTECTED]> wrote: > >>>>>>> I really liked the idea of Maven2 when I heard about it, and > >>>>>>> when a fellow developer used it successfully to build a small > >>>>>>> library for me, I thought it was time to jump in. > >>>>>>> > >>>>>>> Three weeks later I have managed to accomplish very little on > >>>>>>> my project, and I've converted four simple Ant build files into > >>>>>>> 7 Maven pom.xml's that, by and large, don't work. > >>>>>>> > >>>>>>> THE IMPLEMENTATION PROBLEMS > >>>>>>> To advertise Maven 2 as "stable" is, I believe, a disservice to > >>>>>>> developers. In my experience with it, "early beta" would be a > >>>>>>> kind description. > >>>>>>> > >>>>>>> After struggling for the first week with broken links and > >>>>>>> dead-ends on the web pages, I subscribed to the users list and > >>>>>>> found out there is a "secret" book that documents much of Maven > >>>>>>> (ok, it's not really secret, but should I really have to > >>>>>>> subscribe to a mailing list to find out there is more > >>>>>>> documentation?). > >>>>>>> > >>>>>>> Of course, the secret book also documents features that aren't > >>>>>>> released yet (wagon is what bit me). Perhaps that's why it's > >>>>>>> secret. > >>>>>>> > >>>>>>> So now I'm using a "stable" product (incorporating several > >>>>>>> unreleased and poorly documented snapshots) and what happens? > >>>>>>> New releases of a number of modules come out and everything > >>>>>>> breaks! Have I specified a release where I shouldn't have? > >>>>>>> Have I NOT specified a release where I SHOULD have? Based on > >>>>>>> the limited traffic of the problem on the user's list, I can > >>>>>>> only conclude that most people that use Maven are building the > >>>>>>> plugins/modules and that very few people actually use it to > >>>>>>> build applications. > >>>>>>> > >>>>>>> THE DESIGN PROBLEMS > >>>>>>> But my real beef comes to design decisions that I think needs > >>>>>>> some serious consideration. > >>>>>>> > >>>>>>> MAVEN HIDES TOO MUCH. > >>>>>>> > >>>>>>> It really is nice advertising to say "Look! This 12 line > >>>>>>> pom.xml builds this huge project". But that's only if you > >>>>>>> happen to want to do EXACTLY that ONE thing (which seems to be: > >>>>>>> build a Maven plugin). The real world is more complicated. > >>>>>>> And as soon as I want to get more complicated, Maven obliges me > >>>>>>> by getting WAY more complicated. Most of this complication is > >>>>>>> due to, I believe, hiding too much from me. > >>>>>>> > >>>>>>> Why is it that I'm expected, as a developer, to be able to > >>>>>>> download and compile snapshots of plugins that aren't released > >>>>>>> yet (the jnlp plugin), but I'm not expected to understand a > >>>>>>> FULL LIFE CYCLE build file? > >>>>>>> > >>>>>>> You have this wonderful archetype mechanism, why don't you use > >>>>>>> it to make a pom.xml that actually includes information for > >>>>>>> everything it does? This would be self-documenting to > >>>>>>> developers. Isn't the target audience developers? > >>>>>>> > >>>>>>> I believe Maven is hiding the actual build structure, and that > >>>>>>> that is a bad thing. > >>>>>>> > >>>>>>> I have used a number of open source projects where the > >>>>>>> configuration file is used to document the product! It is MUCH > >>>>>>> more enlightening to see a comment with a commented-out section > >>>>>>> than, well, nothing. > >>>>>>> > >>>>>>> An example: I use Java 1.5. The Maven default is 1.4. Can I > >>>>>>> simply search for "1.4" in the pom.xml and change it to "1.5". > >>>>>>> Nooooo. I have to research which plugin actually sets this > >>>>>>> value, how it sets this value, and add 9 lines to my pom.xml > >>>>>>> (assuming I did not yet have any plugins configuration). > >>>>>>> > >>>>>>> THE CENTRAL REPOSITORY PROBLEM > >>>>>>> I think the second major design problem is the central > >>>>>>> repository. As evidenced by the hardware failure at > >>>>>>> codehaus.org, this is a single-point-of-failure that is simply > >>>>>>> unacceptable in real world build situations. > >>>>>>> > >>>>>>> Not only does it represent a single-point-of-failure, it's not > >>>>>>> frozen. I could never see my company using Maven unless we set > >>>>>>> up our own version of the repository, and probably only if we > >>>>>>> used it exclusively, since we require complete build > >>>>>>> reproducibility. Relying on an external organization to not > >>>>>>> make "secret" updates (as has been recently discussed) is > >>>>>>> simply unacceptable. I haven't tried to set up a "central" > >>>>>>> repository, but from scanning messages on the user's list, it > >>>>>>> sounds somewhat less than well defined. > >>>>>>> > >>>>>>> Personally (for open-source projects), I can probably use it, > >>>>>>> but there is going to be a nagging suspicion when something > >>>>>>> breaks. > >>>>>>> > >>>>>>> So, for small users it represents a roadblock when the > >>>>>>> repository is unavailable, and for large users it represents a > >>>>>>> reproducibility problem. > >>>>>>> > >>>>>>> CONCLUSION: > >>>>>>> I think Maven is just "not ready for prime time". I really > >>>>>>> want to like it. I think there are some great ideas, and > >>>>>>> clearly some really smart people working on it. > >>>>>>> > >>>>>>> I hope this rant can be taken constructively. I want projects > >>>>>>> like this to succeed, I really do. > >>>>>>> > >>>>>>> And, please, I understand I'm one person. This is MY view of > >>>>>>> attempting to use Maven to build MY projects. Perhaps I'm just > >>>>>>> not the target audience. Perhaps I'm just out in left field. > >>>>>>> Perhaps I've just missed the point completely. > >>>>>>> > >>>>>>> Chas Douglass > >>>>>>> > >>>>>>> --------------------------------------------------------------- > >>>>>>>------ 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] > >> > >> -------------------------------------------------------------------- > >>- 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] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
