On 9/27/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > 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.
Really... well Eclipse seems to have solved the problem.... I point eclipse at a directory structure and it makes a reasonably good crack at it. remember we are not talking about perfect here. if maven can just do what eclipse 3.3 can do today that's half the battle. do you spend a long time on this trying to be perfect? no of course not because a pom is generated once. but If I get confused about how I want to do something I might just move the pom to one side and ask maven to regenerate the pom just to see what it comes up with (think about this as a form of help). > 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. Most of my broken pom's come in the form of plugin configuration that the plugin either doesn't recognize or it complains about. (but doesn't help out with any suggestions) But another example is I run a new build and all of a sudden a jar that is not mentioned in my pom starts downloading . While not "broken" per-se the pom is broken in that it is now not doing what I expect. I didn't change anything, but new files are getting downloaded and included in my production war file. In this case, a message that says 'downloading foo.jar because it is needed by (dependency tree)'. add exclusion to my/module1/pom.xml to remove this dependency.
