maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth McDonald <>
Subject Re: maven is a swamp
Date Thu, 14 Oct 2010 21:56:31 GMT
>> 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),
>    <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></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: ""
			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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message