>> Hi Wayne, I'll post one more response to your well-thought-out question. >> >> Here is the pom file I'm currently using: >> >> and just so you don't have to scroll all the way to the bottom to see the >> comments, I'll put them here :-) >> >> - Is there _anything_ in the structure of this file which leads me to an >> "aha, I understand what the major >> and minor parts of the file are all about" moment? >> >> - Does the file get across what it means both concisely and clearly? >> >> - Is the syntax of the file for the convenience of the programmer, or the >> convenience of the tools >> that process it? >> >> - Could someone well-versed in programming, but without an understanding of >> maven, make at >> least some sense of this file? >> >> IMHO, the answers are no, no, for the convenience of the tools, and no. In >> terms of readability, >> this file (and all pom files I've seen) are simply disasters. In terms of >> semantics--OK, pretty good. >> In terms of usability, what a piece of garbage! > > But why would you ever see this? > Doesn't your IDE support Maven?
I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes me look at the pom as xml. But even that begs the question. > There is no reason why any of my guys would ever look at this as XML. > We use Eclipse/STS as an IDE and this simple POM would never require anyone > to do anything in XML. > > Hand editing POMs is not a reasonable thing to do in 2010 unless you are > debugging Maven and want to break a POM to see what Maven does. > I agree. Hand editing POMs is not reasonable because POMs are not amenable to hand editing. That's a problem of the POM format, not of the concept of hand editing. > You need to look at parent POMs to get rid of the clutter: > > This goes in the project parent POM so you don't put it in a POM that > generates an artifact: That may be the case (and is something that is nonobvious from reading basic maven docs), but... > > <developers> > <developer> > <id>kmcdonald</id> > <name>Kenneth McDonald</name> > <email>ykkenmcd [at] gmail com</email> > </developer> > </developers> > > <licenses> > <license> > <name>Lesser General Public License (LGPL)</name> > <url>http://www.gnu.org/copyleft/lesser.txt</url> > <distribution>repo</distribution> > </license> > </licenses> > developers = [{id: "kmcdonald", name: "Kenneth McDonald", email: "ykkenmcd [at] gmail com"}] licenses = [ { name: "Lesser General Public License (LGPL)", url: "http://www.gnu.org/copyleft/lesser.txt"; distribution: "repo" } ] That's ten lines of code vs. fifteen, and the ten lines are _much_ more readable. And I could've compressed those ten lines further without much effort. C'mon, people, where's your sense of proportion? The syntax I've used is pretty Pythonic (not sure if it's exactly that since I've used Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_ time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the problem with using a syntax that is: a) easily parsed b) easily read c) easily written Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that things should be text _unless_ they are explicitly marked as not text. This completely flies in the face of I don't know how many years of CS, and is simply wrong. Most of most coding constructs is control logic. It follows that it should be easy to write the control logic, a little bit more difficult to write the literals. Now when HTML was being designed, that was different, because they were designing to a format whose primary purpose was visual represention on a page. Guess what, boys and girls--we're not doing that anymore! XML is a control format, and should make it easy to write the control parts of the statements, and a little tougher to write the literal parts. The fact that it doesn't do this is evidence if its almost complete inadequacy to serve as a control language. ...I've edited out a lot here below for brevity. Cheers, Ken --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
