Just had a crazy thought about the "external organization making secret changes" issue. If the issue is with snapshot builds I guess I don't have much for you there (other than the above, of course). However if the concern is simply that you don't know that what's in the repository hasn't changed, I had a wacky idea.
Maybe we write a plugin that does the following. When you set up a new project or change an existing project's dependencies, you need to run that plugin. Something like: mvn depend-check:build It'll go through non-snapshot dependencies and build a datafile that keeps a hash of each of the artifacts. Keep that in the root directory next to the 'pom.xml' file, and more importantly, keep it in source control. Attach the plugin to the build, although the goal would be like 'depend-check:check'. This plugin would consult with the datafile built earlier and check that each local artifact matched what was used originally for the build. If something doesn't match, you'll get an error and an aborted build. I mean, personally, I'm not awake at night worried that struts 1.2.9 is different than it was 3 months ago, but I understand from where your concern comes. Of course, I'm exhausted, so maybe my idea is impratical or whatever, but I think it would serve as a decent sanity check. if just knowing that something is not right isn't enough, maybe as part of the release or deploy plugins you can optionally stuff a copy of all artifacts somewhere. As to maven being bleeding edge and being quirky, I'd agree. However, at this point I wouldn't start a new project without it. And, believe me, I'm the first guy to scream "Emporer's New Clothes" when people get overly excited about some hyped new thing. I'm sure I've convinced you ;) On 5/26/06, Kathryn Huxtable <[EMAIL PROTECTED]> wrote:
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]
