Uh, I guess so. ;-) I did mean "he". Sorry, I was up late last night playing Civilization IV. (I really need to lock my Dell up in a drawer.) I shouldn't touch a keyboard lest I break something.
-K, off to bed On 5/25/06 6:40 PM, "Lee Meador" <[EMAIL PROTECTED]> wrote: > Uh .. when HE made an error. Is that another test? > > On 5/25/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote: >> >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
