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]
