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
