Yeah - you can acutally find where the error is most of the time by running
mvn -e [blah:blah] It's in the stack trace. But you're right, one would hope it would print to the screen. -- Eric Redmond http://blog.propellors.net On 9/27/07, Lee Meador <[EMAIL PROTECTED]> wrote: > > The way I usually get a broken pom is to copy a snippet of xml from > somewhere and paste it one line above where it goes. For example, I need a > new dependency in some child pom. I go to the parent where I have all my > versions in dependency management and select a <dependency> section for > the > thing I want to add. Then I copy it into the child pom and remove the > version number line. Maybe I add a "test" or "comple" section. > > But, lacking sufficient eye-hand coordination (I suppose that's why I'm > not > a big sports star), I put it one line up so it goes inside another > <dependency> section and I get an XML parsing error. Since I know I just > changed it, I go look there and see the stupid error. But the error > doesn't > seem to tell me a line number or print out any context that helps me find > it. > > Another one I do is add xml comment marks <!-- --> around a section that > already has something commented in it. This, of course, is an xml parsing > error as well. > > -- Lee > > On 9/27/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > > 1. If maven has no pom in current directory. mvn should display > help > > > similar to this from perforce: > > > > This sounds reasonable. Other people have requested similar > > functionality. We should make sure this lands in JIRA for future > > implementation. > > > > > 2. have "mvn help" be able to run out of the box with *no > downloads* > > > being required. > > > > I agree, but I'm not sure how it should be implemented given that > > "help" is simply a plugin like all the others. So we'd need to bundle > > it with the zip, and then force the user to run a script to install it > > in the proper place etc as part of the installation. And then if they > > change their local repo cache location, they'll need to run it again > > to copy it there too. > > > > > 3. have the concept of a reverse archetype -- mvn runs and figures > > out > > > what the pom.xml should look like based on the current directory > > > structure. Currently the archetype concept says "*if* you make your > > > directory structure look like this mvn can run". Most projects do > not > > have > > > this luxury. > > > > This is simply an NP-hard problem and will *never* be implemented. > > Every single project is (radically) different. > > > > > 4. if a pom is "broken" mvn should offer a suggestion about how to > > fix > > > it. > > > > What kind(s) of broken poms should be recoverable/detectable/fixable? > > Other than XML which is not well-formed, I very infrequently get > > broken poms personally, so I'd like to hear more suggestions. > > > > Wayne > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > -- Lee Meador > Sent from gmail. My real email address is lee AT leemeador.com >
