I actually meant scpexe. "I was just testing you," as my ex-father in law would say when I made an error.
-K On 5/25/06 5:45 PM, "ben short" <[EMAIL PROTECTED]> wrote: > Yes you use the maven-proxy to serve the internal repository. > > What do you mean my sshext? > > Ben > > On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: >> Yes, it helps, as does Daniel Kulp's message. You don't need to proxy your >> inhouse repo, but you can just to simplify things. >> >> My issue is that I'm at a university, where I don't have a developer >> intranet for my team, so my inhouse repo is accessed via sshext for access >> control reasons. >> >> If my VPN were smarter I could use Apache's access control mechanisms to >> restrict access to the team, but it's pretty limited. >> >> If access control were easier to delegate I maybe could use Shibboleth or >> something. (I manage Shibboleth for our campus.) >> >> -K >> >> >> On 5/25/06 5:11 PM, "ben short" <[EMAIL PROTECTED]> wrote: >> >>> Well you wouldnt. >>> >>> The proxy is used to cache ( and persist ) the dependancies that are >>> hosted on the remote maven repos, like codehaus and ibilo. The means >>> that your developers have access to the dependacies at a high speed, >>> after they have been downloaded by the proxy. >>> >>> Now an inhouse repositry would be seperate. In this you would store >>> all the jar that you produce and want to share between your >>> development team. >>> >>> Does that help? >>> >>> Ben >>> >>> On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> 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] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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]
