Re: [Repetitive]: Maven does not live up to its promises
If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Yeah, but a build often does not fit on a page, and I'm building some pretty simple stuff! To argue for the flexibity of Maven is (AFAIK) defensible. It's power (from what little knowledge I have), likewise. But, I'm sorry to say, the verbosity of XML is a major, major issue. I bring you back to the simple fact of: If XML were so expressive, why aren't most modern languages written in XML? If programmers had to write their systems in a dialect of XML, put in the redundant tags, escape everything that _isn't_ a literal, etc., then we would have very poor programmer productivity. I've looked at pages and pages of POM files, trying to learn things. And my conclusion is that Maven was _fundamentally flawed_ in choosing XML as its base. Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Perhaps you'd be interested in Polyglot Maven? http://polyglot.sonatype.org/ --b __ Brian M. Carr Identity and Access Management ITS Applications University of Texas at Austin V: 512-232-6419 F: 512-471-5746 brianmc...@austin.utexas.edu On Oct 26, 2010, at 1:56 PM, Kenneth McDonald wrote: If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Yeah, but a build often does not fit on a page, and I'm building some pretty simple stuff! To argue for the flexibity of Maven is (AFAIK) defensible. It's power (from what little knowledge I have), likewise. But, I'm sorry to say, the verbosity of XML is a major, major issue. I bring you back to the simple fact of: If XML were so expressive, why aren't most modern languages written in XML? If programmers had to write their systems in a dialect of XML, put in the redundant tags, escape everything that _isn't_ a literal, etc., then we would have very poor programmer productivity. I've looked at pages and pages of POM files, trying to learn things. And my conclusion is that Maven was _fundamentally flawed_ in choosing XML as its base. Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: [Repetitive]: Maven does not live up to its promises
I've looked at pages and pages of POM files, trying to learn things. And my conclusion is that Maven was _fundamentally flawed_ in choosing XML as its base. XML isn't evil. XML is a compromise between human-readable and computer-readable data. It's neither the best nor the worst format. If you want something more friendlier, check out Polyglot Maven. Also, XML isn't the memory representation of Maven's data structures. XML is just the expressed format. So it's not a fundamental flaw by any stretch. Paul On Tue, Oct 26, 2010 at 1:56 PM, Kenneth McDonald kenneth.m.mcdon...@sbcglobal.net wrote: If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Yeah, but a build often does not fit on a page, and I'm building some pretty simple stuff! To argue for the flexibity of Maven is (AFAIK) defensible. It's power (from what little knowledge I have), likewise. But, I'm sorry to say, the verbosity of XML is a major, major issue. I bring you back to the simple fact of: If XML were so expressive, why aren't most modern languages written in XML? If programmers had to write their systems in a dialect of XML, put in the redundant tags, escape everything that _isn't_ a literal, etc., then we would have very poor programmer productivity. I've looked at pages and pages of POM files, trying to learn things. And my conclusion is that Maven was _fundamentally flawed_ in choosing XML as its base. Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Kathyrn I greatly appreciate the feedback. I've looked at using your system but (correct me if I'm wrong), it doesn't maintain simulteneity of source and docs. In other words, I have to upload the docs seperately from the source? This is important to me. I regard a release as a juxtaposition of properly correlated source and docs. That's what I'm aiming at. Thanks, Ken On Oct 25, 2010, at 9:54 AM, Kathryn Huxtable wrote: I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads your site documentation to github. It hasn't been verified to work with Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if you're interested. -K On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things
Re: [Repetitive]: Maven does not live up to its promises
On 26 Oct 2010, at 8:56 PM, Kenneth McDonald wrote:
Yeah, but a build often does not fit on a page, and I'm building
some pretty simple stuff!
To argue for the flexibity of Maven is (AFAIK) defensible. It's
power (from what little knowledge I have), likewise.
But, I'm sorry to say, the verbosity of XML is a major, major issue.
You've said that a number of times, but I haven't yet seen a solid
justification for it. For me, it's a non issue. If it doesn't fit on a
screen, I scroll down. I can scan and read if by hand if I need to,
but way more often, I validate the structure against an XSD, and the
system finds my mistakes for me. And I never see any need for this:
foo() {
.
.
.
} /* foo */
I leave my pom files to the defaults as far as possible, and that
means options aren't set. Those that are set are neatly sectioned off,
with comments if necessary to explain something that may not be
obvious to the eye.
The code is in a separate project to the archive (jar, war, etc),
which is in a separate project to the assemblies. When the pom gets
too long, it's a clear sight the project should be broken up into
smaller more manageable pieces. Sometimes these are all released
separately with different version numbers, most often they all share
the same version in a multi module project. I don't know or care,
maven-release-plugin cares about version numbers.
I get the sense that you're bitterly opposed to XML, and by extension,
anything else that uses XML, and while maven uses XML, you'll be
opposed to maven. This is not a problem maven can fix for you.
I bring you back to the simple fact of: If XML were so expressive,
why aren't most modern languages written in XML?
Because if language designers agreed on a common syntax they would
have also agreed on a common language?
You're again making a mistake that maven pom files are somehow a
language, in the way that ant build files are.
Pom files are a hierarchical collection of facts, they are not a
sequence of instructions. XML is really good at solving this problem.
Maven is not ant.
I've looked at pages and pages of POM files, trying to learn things.
And my conclusion is that Maven was _fundamentally flawed_ in
choosing XML as its base.
They had to choose something, and the world didn't need another custom
syntax.
Regards,
Graham
--
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On 26/10/2010 2:56 PM, Kenneth McDonald wrote: If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Yeah, but a build often does not fit on a page, and I'm building some pretty simple stuff! To argue for the flexibity of Maven is (AFAIK) defensible. It's power (from what little knowledge I have), likewise. But, I'm sorry to say, the verbosity of XML is a major, major issue. I bring you back to the simple fact of: If XML were so expressive, why aren't most modern languages written in XML? If programmers had to write their systems in a dialect of XML, put in the redundant tags, escape everything that _isn't_ a literal, etc., then we would have very poor programmer productivity. I've looked at pages and pages of POM files, trying to learn things. And my conclusion is that Maven was _fundamentally flawed_ in choosing XML as its base. People that love to edit XML by hand must love XML People that hate XML use editors. OpenOffice and Microsoft both store documents in XML but I never use XML to create a spreadsheet. Do I find XML an impediment to using spreadsheets? No. Do I regard the pages of XML that makes up a spreadsheet to be a fatal flaw? I would if I had to enter the document in XML. Have you even looked at a POM editor? You are making a mountain out of something that is not an issue. GET AN EDITOR and never see XML again in a POM file. If your IDE does not support editing of POM files switch IDE's or bug the authors to include an editor. Why pester us with your whining if you don't like the way your IDE edits POM files? Go to the forum where your IDE is discussed and complain to them that the IDE does not support POM files properly. Tell them that you heard about Eclipse/STS and the users of that IDE do not have to deal with XML in POM file. Ron Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
I get the sense that you're bitterly opposed to XML, and by extension, anything else that uses XML, and while maven uses XML, you'll be opposed to maven. This is not a problem maven can fix for you. This seems to be the root of his problem with Maven, and its not something that we're going to solve by discussing it on the user list. I don't understand the opposition to the format either. Most config files I deal with these days are in XML, and yet I haven't seen anyone ranting like this on the Weblogic forums complaining about config.xml, nor people complaining about web.xml for configuring servlets, etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
It uploads the site documentation using the site:deploy target, the same as any Maven site deploy. If you have generated source listings, those will be uploaded. Yes, it is separate from source commits. That's standard. Apparently the Maven developers rather wish that site generation hadn't been included in the POM, but since it is, they're not removing it. To them, the source and documentation are completely separate. You'd like documentation to be generated, released, and tagged simultaneously with a release:prepare target? That's probably doable with a plugin. The plugin may not currently exist, however. -K On Oct 26, 2010, at 2:14 PM, Kenneth McDonald wrote: Kathyrn I greatly appreciate the feedback. I've looked at using your system but (correct me if I'm wrong), it doesn't maintain simulteneity of source and docs. In other words, I have to upload the docs seperately from the source? This is important to me. I regard a release as a juxtaposition of properly correlated source and docs. That's what I'm aiming at. Thanks, Ken On Oct 25, 2010, at 9:54 AM, Kathryn Huxtable wrote: I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads your site documentation to github. It hasn't been verified to work with Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if you're interested. -K On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how
Re: [Repetitive]: Maven does not live up to its promises
On Oct 26, 2010, at 4:48 PM, Wayne Fay wayne...@gmail.com wrote: I don't understand the opposition to the format either. Most config files I deal with these days are in XML, and yet I haven't seen anyone ranting like this on the Weblogic forums complaining about config.xml, nor people complaining about web.xml for configuring servlets, etc. I complain about web.xml all the time. But that's because it doesn't support regex, not because it is XML. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [Repetitive]: Maven does not live up to its promises
Jason, if you do that can you post the link in this list too, please? I would like to read it and I very seldom go check blogs, but I check my email daily. :) -Original Message- From: Jason van Zyl [mailto:ja...@maven.org] Sent: Sun 10/24/2010 6:03 AM To: Maven Users List Subject: Re: [Repetitive]: Maven does not live up to its promises Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come
Re: [Repetitive]: Maven does not live up to its promises
I've tried to come up with a 'moderate' reprocessing of this dispute before, and for some reason I'm going to try again. The fundamental idea of Maven is that a build can be described with a small number of facts. This is possible if the right conventions are analyzed, designed, and implemented into the build system. If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Further, historically, Maven came behind Ant. If there's one thing worse that a few facts in XML, it's many, many, facts, and a small procedural language, in XML. For many purposes, and on many occasions, Maven succeeds in the 'fundamental idea' above. There is, however, a however. In some cases, POMs grow hair. Posters to this list sometimes seem to believe that every bit of that hair is illegitimate -- that it either reflects ignorance of 'the maven way,' or it reflects insufficient willingness to create new maven plugins. I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/ plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. However, over-focussing on the supposed intrinsic evil of XML, either on the complaint or the defense side, is a distraction. In my opinion, the real question is, What would it take to keep 'maven way' POMs from growing and ramifying out of maintainability? Generalize the 'main versus site' lifecycle to allow multiple lifecycle definitions, defined once, and reused in many poms? Some way to package up a gang of plugin specs for reuse? Support for 'include'? Tighter XML for common cases? My favorite in this area is goals. Oh how I wish for: execution id='id' phase='phase' goal='goal' ... /execution - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [Repetitive]: Maven does not live up to its promises
VERY well said Ben. You get my vote here. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, October 25, 2010 8:27 AM To: Maven Users List Subject: Re: [Repetitive]: Maven does not live up to its promises I've tried to come up with a 'moderate' reprocessing of this dispute before, and for some reason I'm going to try again. The fundamental idea of Maven is that a build can be described with a small number of facts. This is possible if the right conventions are analyzed, designed, and implemented into the build system. If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Further, historically, Maven came behind Ant. If there's one thing worse that a few facts in XML, it's many, many, facts, and a small procedural language, in XML. For many purposes, and on many occasions, Maven succeeds in the 'fundamental idea' above. There is, however, a however. In some cases, POMs grow hair. Posters to this list sometimes seem to believe that every bit of that hair is illegitimate -- that it either reflects ignorance of 'the maven way,' or it reflects insufficient willingness to create new maven plugins. I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/ plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. However, over-focussing on the supposed intrinsic evil of XML, either on the complaint or the defense side, is a distraction. In my opinion, the real question is, What would it take to keep 'maven way' POMs from growing and ramifying out of maintainability? Generalize the 'main versus site' lifecycle to allow multiple lifecycle definitions, defined once, and reused in many poms? Some way to package up a gang of plugin specs for reuse? Support for 'include'? Tighter XML for common cases? My favorite in this area is goals. Oh how I wish for: execution id='id' phase='phase' goal='goal' ... /execution - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
The point of XML is not that it is a language in the way natural or programming languages are. The point is it provides a standard machine AND human readable way of representing structured data. Yes, it's not terribly fun or straightforward to edit XML in a text editor. That's why XML aware editors exist. If a suitable DTD or schema exists, the XML editor can keep you away from stupid syntax or misspellings that take time and energy to track down while you're executing your thing. Because XML is a widespread standard, there are lots of XML parsers and generators out there. The problem with Maven isn't that it uses XML, it's that there isn't (as far as I know) aren't amazing tools to help you write the XML. The Maven plugin for Eclipse provides some support, but frequently defaults to use the XML tab. The XML editor may not ensure you have the correct tags but at least it helps you get the structure (spelling and closing) correct. Another helpful tool is tidy -- frequently when I'm done editing an XML -- such as a copy/paste from an online example -- I can use tidy to detect gross errors reformat it nicely. The human readable part is important because with a binary file, when things go wrong can be hard to tell whether the file or tool you're using is incorrect. At least with XML you can go read it yourself, even if nountags/noun verbdo/verb verbmake/verb pronounit/pronoun adjectiveawkward/adjectivepunctuation type=emphasis!/punctuation. In any event, Maven does many things for free that I couldn't do nearly as quickly without it. On 10/24/10 12:44 PM, Kenneth McDonald wrote: On Oct 23, 2010, at 7:10 PM, Néstor Boscán wrote: XML is one of the most widespread and flexible languages out there, accept it, move on. XML is not a language, it is merely a way of specifying structured data. To the extent that your structured data does or does not have control structures, internal data structures, standard procedural/functional manipulations, etc., _then_ you have or have not a language. My contention (one of them) has always been that XML's syntax is poorly suited for human understanding of complex structures. And in defense, I still maintain that if XML were so great at this stuff, people would be writing new languages in XML, forcing programmers to program in XML...which hasn't happened. There's one language I'm aware of which uses XML for its syntax (can't remember the name), and it seems to have sunk from sight. A _huge_ amount of work goes into grammars and parsers when languages are being defined. This is no accident. A good grammar (language design) can make all the difference between a language that will be widely used, and one that will hardly be used. I just don't understand why people think that languages based on XML are somehow above the fray. Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Thus what you are waiting for are : - Maven polyglot which will allow to write the pom in various formats (simplified xml, groovy, whatever) : http://polyglot.sonatype.org/ - Mixins which will allow to inject part of poms and thus ease how we can reuse them : http://www.sonatype.com/people/2008/11/maven-project-model/ It's cool, it's on its way ... On Oct 25, 2010, at 2:26 PM, Benson Margulies wrote: I've tried to come up with a 'moderate' reprocessing of this dispute before, and for some reason I'm going to try again. The fundamental idea of Maven is that a build can be described with a small number of facts. This is possible if the right conventions are analyzed, designed, and implemented into the build system. If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Further, historically, Maven came behind Ant. If there's one thing worse that a few facts in XML, it's many, many, facts, and a small procedural language, in XML. For many purposes, and on many occasions, Maven succeeds in the 'fundamental idea' above. There is, however, a however. In some cases, POMs grow hair. Posters to this list sometimes seem to believe that every bit of that hair is illegitimate -- that it either reflects ignorance of 'the maven way,' or it reflects insufficient willingness to create new maven plugins. I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/ plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. However, over-focussing on the supposed intrinsic evil of XML, either on the complaint or the defense side, is a distraction. In my opinion, the real question is, What would it take to keep 'maven way' POMs from growing and ramifying out of maintainability? Generalize the 'main versus site' lifecycle to allow multiple lifecycle definitions, defined once, and reused in many poms? Some way to package up a gang of plugin specs for reuse? Support for 'include'? Tighter XML for common cases? My favorite in this area is goals. Oh how I wish for: execution id='id' phase='phase' goal='goal' ... /execution - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Comments interspersed below. Ron On 25/10/2010 8:26 AM, Benson Margulies wrote: I've tried to come up with a 'moderate' reprocessing of this dispute before, and for some reason I'm going to try again. The fundamental idea of Maven is that a build can be described with a small number of facts. This is possible if the right conventions are analyzed, designed, and implemented into the build system. If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Further, historically, Maven came behind Ant. If there's one thing worse that a few facts in XML, it's many, many, facts, and a small procedural language, in XML. For many purposes, and on many occasions, Maven succeeds in the 'fundamental idea' above. There is, however, a however. In some cases, POMs grow hair. Posters to this list sometimes seem to believe that every bit of that hair is illegitimate -- that it either reflects ignorance of 'the maven way,' or it reflects insufficient willingness to create new maven plugins. Don't underestimate the desire to continue to use bad workflow and poor project structures. I would also add in the ease with which plug-in are created as a negative influence in some cases. Just because maven CAN do it does not mean that your SHOULD do it. Sometimes the plug-in does not already exist because there is a better way to get the workflow to do what is required. The helpful people on this list are very good at responding to specific questions about how to do something without asking Why is such a workflow required? I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/ plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. However, over-focussing on the supposed intrinsic evil of XML, either on the complaint or the defense side, is a distraction. In my opinion, the real question is, What would it take to keep 'maven way' POMs from growing and ramifying out of maintainability? Hints: JNDI Common libraries for chunks of shared functionality SOA None of these have to do with Maven directly but trying to use Maven to solve the problems caused by not using these technologies correctly is a lot of work and requires all kinds of gymnastics with plug-ins. Anyone writing a custom plug-in really needs to examine why they have wandered off the Best Practice road into the bushes. It may be justified but be prepared for a bumpy ride and in the end you may not get to your destination as quickly as you would if you followed the Best Practices. Generalize the 'main versus site' lifecycle to allow multiple lifecycle definitions, defined once, and reused in many poms? Some way to package up a gang of plugin specs for reuse? Support for 'include'? Tighter XML for common cases? My favorite in this area is goals. Oh how I wish for: execution id='id' phase='phase' goal='goal' ... /execution - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads your site documentation to github. It hasn't been verified to work with Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if you're interested. -K On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things for which it's not, that why would you spend all of your time there? I don't have an answer. Anyway /end of rant Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/ plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. Hints: JNDI Common libraries for chunks of shared functionality SOA None of these have to do with Maven directly but trying to use Maven to solve the problems caused by not using these technologies correctly is a lot of work and requires all kinds of gymnastics with plug-ins. Ron, You seem to want to take an extreme view here, in which you believe that absolutely every case of Maven complexity (whether in POM or in Plugins) results from mistakes. Is that really the position you want to take, or are you just looking to be emphatic that *many* of the distress-calls here are really because of mistakes. Someone of us have to arrange interoperation with things we don't control, and which do misuse some of these technologies. We can't just yell at the sources. We have to come up with something. Have a look, some time, at the POM structure at cxf.apache.org. The shared parent is over 1,500 lines. A notable fraction of that is dependency exclusions, which in some cases are repeated, over and over and over, because all of the Spring artifacts have all of the same unwanted dependencies. Another source of complexity is the limitations of aggregation. We can't get the right javadoc by just aggregating. We have to package up with the maven-source-plugin, then unpack, and regenerate the javadoc. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Hi, On Mon, Oct 25, 2010 at 1:46 PM, Benson Margulies bimargul...@gmail.com wrote: Have a look, some time, at the POM structure at cxf.apache.org. The shared parent is over 1,500 lines. A notable fraction of that is dependency exclusions, which in some cases are repeated, over and over and over, because all of the Spring artifacts have all of the same unwanted dependencies. My top-level corporate POM is over 3,000 lines long, mostly for dependencyManagement and default plugin configurations. The bonus is that most of my satellite POMs are less than 100 lines long. Anyhow, a very clever way to bypass the problem you guys have with specifying exclusions for multiple artifacts (presumably commons-logging) is to specify them as dependencies but with scope=provided. Then you need not specify, let alone repeat, exclusions anywhere else.. Before The Maven Way Police come banging down my office door, I should say that the scope is not being abused in that we use slf4j everywhere and so the jcl-over-slf4j really does justify the scope=provided -- but regardless, only the most die hard Mavenites would critique you on this subtle point. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On 25/10/2010 1:46 PM, Benson Margulies wrote: I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of reporting/plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. Hints: JNDI Common libraries for chunks of shared functionality SOA None of these have to do with Maven directly but trying to use Maven to solve the problems caused by not using these technologies correctly is a lot of work and requires all kinds of gymnastics with plug-ins. Ron, You seem to want to take an extreme view here, in which you believe that absolutely every case of Maven complexity (whether in POM or in Plugins) results from mistakes. Is that really the position you want to take, or are you just looking to be emphatic that *many* of the distress-calls here are really because of mistakes. I am probably a bit over dramatic. I do find it hard to believe that there are so many ways to assemble and run Java applications. I suspect that if we had a set of Best Practices for developing applications with Maven, a lot of grief could be eliminated. I do get a bit overwrought when I read that people are having trouble with Maven because Operations has to modify POM files or that someone is upset about having to edit XML but will not just switch to an IDE that includes all the editors that you need or people having trouble detecting dependency conflicts when there is a free IDE that does that. Maven is a great tool until you try to bend it or try to insert it into a workflow without examining the changes that you should make to the projects and workflows to get the benefits. If one does not want change, then Maven will not be their friend and they should stick with Ant. Someone of us have to arrange interoperation with things we don't control, and which do misuse some of these technologies. We can't just yell at the sources. We have to come up with something. Have a look, some time, at the POM structure at cxf.apache.org. The shared parent is over 1,500 lines. A notable fraction of that is dependency exclusions, which in some cases are repeated, over and over and over, because all of the Spring artifacts have all of the same unwanted dependencies. We use CXF and I know that they have some packaging issues. I would certainly look at how to repackage their application in a larger number of POM that were: 1) more stable 2) smaller They should also look at better management of property files. I do appreciate the fact that if you look hard enough, you can find a consolidated jar for CXF that does give a full and consistent set of property files. It is also very easy to use and quite reliable and robust. Our portal has over 60 POMs but the parent is very small (only plug-in dependencies and repo information) and each project POM has only 3-6 dependencies that never change except for their own version and the version of the core software release which is held in a single property and used to select the appropriate aggregate libraries. The projects pick up Spring, Hibernate, Tomcat, MySQL in a single dependency which actually depends on several other POMs. These hardly ever change and are very simple. We centrally manage the dependency on third party libraries so the developers do not have to worry about the 50+ tools that make up our core set of third party libraries. We only use 3 or 4 of the most common and standard plug-ins and yet get to build and deploy a large portal application. We have no custom plug-ins. Another source of complexity is the limitations of aggregation. We can't get the right javadoc by just aggregating. We have to package up with the maven-source-plugin, then unpack, and regenerate the javadoc. This is an area that we have not looked at since we are using Eclipse and it can navigate the libraries better than Javadocs, for what we need. --benson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
s/Wayne/Kenneth/ On Oct 23, 2010, at 8:10 PM, Néstor Boscán nesto...@gmail.com wrote: Wayne XML is one of the most widespread and flexible languages out there, accept it, move on. We could all be investing 5 years in this discussion and we wouldn't be writing code that pays our salaries. I have been using maven on at least 70 java projects succesfully and now is a nightmare for me to work on a project without a pom.xml file. regards, Néstor Boscán On Sat, Oct 23, 2010 at 5:29 PM, Wayne Fay wayne...@gmail.com wrote: an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? I didn't say it before (saved as draft)... but I'd encourage you to create this Prolog-based build system in your free time over the next few months [perhaps use the time you'd otherwise be writing rants about Maven, you'll have it built in no time :)] and if the community decides it is a superior system for building Java (and other language) applications, the forces of natural selection and evolution will win out and Maven will die a quiet death at the hands of your Prolog-builder. PS- What's the fascination with Prolog? Do you own patents in Prolog and get paid every time someone compiles or runs a Prolog application... or merely mentions it in an email? :D Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things for which it's not, that why would you spend all of your time there? I don't have an answer. Anyway /end of rant Ken - To unsubscribe, e-mail:
Re: [Repetitive]: Maven does not live up to its promises
Hi there, in the first round of the rant I already tried to find an answer to why you where using maven in the first place. Personally, I had my fights with maven; especially wrinting my own plugins; but with the ecosystem of build and quality management tools surrounding it I still consider it superior to the other things I have used. If you don't like XML, why not look at polygloott maven; it seems you can write pom files in other languages now; if Ruby, Groovy and Scala isn't to your liking, maybe zyou can start a Prolog subproject there ... Programmers will always waste their time on current things as it pays the rent and stuff; sometimes something new and better is invented and we will be wasting our stuff on that. Personally I have wasted much time on a lot different technologies, but whenever I felt about something like you feel on maven I kind of walked away from it. Programming should be fun...remember ? :) One thing, if your Prolog based, perfect build tool is ready to be released; perhaps then you could come back to this rant and announce it ... My 0.02€ Andreas Am 10/23/10 11:15 PM, schrieb Kenneth McDonald: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a)
Re: [Repetitive]: Maven does not live up to its promises
Jason- I'm sure there's a lot here to respond to, but if I could make one suggestion, it would be to clarify what you/we mean when we say that Maven is 'declarative'. This seems, at least for Mr. McDonald, to be the source of some confusion. Just my 2 cents... Justin On Oct 24, 2010, at 9:03 AM, Jason van Zyl ja...@maven.org wrote: Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to
Re: [Repetitive]: Maven does not live up to its promises
On Oct 24, 2010, at 11:15 AM, Justin Edelson wrote: Jason- I'm sure there's a lot here to respond to, but if I could make one suggestion, it would be to clarify what you/we mean when we say that Maven is 'declarative'. This seems, at least for Mr. McDonald, to be the source of some confusion. That would definitely be one of the clarifications. Just my 2 cents... Justin On Oct 24, 2010, at 9:03 AM, Jason van Zyl ja...@maven.org wrote: Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of
Re: [Repetitive]: Maven does not live up to its promises
Fine by me. I'm still looking for maven enlightenment, and if I can contribute to this (even in a negative way), that's great. Ken On Oct 24, 2010, at 8:03 AM, Jason van Zyl wrote: Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things for which it's not, that why would you spend all of
Re: [Repetitive]: Maven does not live up to its promises
On Oct 23, 2010, at 7:10 PM, Néstor Boscán wrote: XML is one of the most widespread and flexible languages out there, accept it, move on. XML is not a language, it is merely a way of specifying structured data. To the extent that your structured data does or does not have control structures, internal data structures, standard procedural/functional manipulations, etc., _then_ you have or have not a language. My contention (one of them) has always been that XML's syntax is poorly suited for human understanding of complex structures. And in defense, I still maintain that if XML were so great at this stuff, people would be writing new languages in XML, forcing programmers to program in XML...which hasn't happened. There's one language I'm aware of which uses XML for its syntax (can't remember the name), and it seems to have sunk from sight. A _huge_ amount of work goes into grammars and parsers when languages are being defined. This is no accident. A good grammar (language design) can make all the difference between a language that will be widely used, and one that will hardly be used. I just don't understand why people think that languages based on XML are somehow above the fray. Cheers, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Nope, no patents/fascination with Prolog. It's just that Maven declares itself to be declarative rather than procedural, and if those terms mean what they usually mean, I can't think why it would have gone to the trouble of spinning an entirely new system, only to ignore, what, 30 years'?, of progress in declarative systems. Why reinvent the wheel? As to why I don't do this myself, the answer is simple: I don't have the technical knowledge to do so. This will, of course, inspire some people to say, Well, he doesn't know what he's talking about, let's ignore him. But I'm a very talented tech writer, with a significant amount of investment in programming. So the former statement could have been something like, He's never implemented anything in MSWord, so why should anything he says about Word be of interest? But of course, the whole point is that I'm a _user_ of these technologies, with an ability to understand what is and is not possible. I comprehend, I really do, the advantages of XML, and I know that one of those advantages is _not_ human readability (except in extremis). And this is what drives me nuts. I remember so many cases of the technology that was going to save the software world. ClearCase. Rational Rose. UML. Fifth gen computing (from which we got Prolog.) So many others. So when I see a potentially hugely useful solution like maven, implemented in terms of XML, it almost makes me want to hurl. XML is not some magic witch's powder that you throw against the world. It's a verbose, redundant, and difficult to read standard for specifying data structures. The one real win we got out of that game, IMHO, was unit testing, which is really and truly a useful technology. And again, I'll say: the mere _existence_ of Maven polyglot should be enough to convince people that Maven, by itself, is not the be-all and end-all. What do I hope to gain from these exchanges, aside from venting some spleen? Well, really, I hope to make at least a few people think that maybe the current solution isn't the ideal, so that when the time comes along for the next solution (as it will), my opinion has some small but noticeable influence. Cheers, Ken On Oct 23, 2010, at 4:59 PM, Wayne Fay wrote: an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? I didn't say it before (saved as draft)... but I'd encourage you to create this Prolog-based build system in your free time over the next few months [perhaps use the time you'd otherwise be writing rants about Maven, you'll have it built in no time :)] and if the community decides it is a superior system for building Java (and other language) applications, the forces of natural selection and evolution will win out and Maven will die a quiet death at the hands of your Prolog-builder. PS- What's the fascination with Prolog? Do you own patents in Prolog and get paid every time someone compiles or runs a Prolog application... or merely mentions it in an email? :D Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [Repetitive]: Maven does not live up to its promises
To me, Maven is two things: a way of *declaring* dependencies between components and a way of *declaring* a transform on assets that comprise these components. The transform says something like: I have some assets in a given form in locationA and I want to transform them into another form in location B. The assets are a bunch of files structured according to certain conventions. The target is typically (but not always) some sort of deployable archive form that adheres to some standard such as a JAR, WAR, EAR or a complex assembly consisting of multiple such forms. This is the essence of the declarative nature (and the magic) of Maven. You can realize this kind of transformation without having to state procedurally the steps required to get there. The XML sucks discussion is one that has been repeated in many other domains and is rarely fruitful. -brian From: ext Jason van Zyl [ja...@maven.org] Sent: Sunday, October 24, 2010 11:21 AM To: Maven Users List Subject: Re: [Repetitive]: Maven does not live up to its promises On Oct 24, 2010, at 11:15 AM, Justin Edelson wrote: Jason- I'm sure there's a lot here to respond to, but if I could make one suggestion, it would be to clarify what you/we mean when we say that Maven is 'declarative'. This seems, at least for Mr. McDonald, to be the source of some confusion. That would definitely be one of the clarifications. Just my 2 cents... Justin On Oct 24, 2010, at 9:03 AM, Jason van Zyl ja...@maven.org wrote: Kenneth do you mind if I use the body of this rant in a blog entry? I will leave it verbatim and won't quote anything out of context. There are many people who misunderstand Maven at a fundamental level, but in sum total not many Maven users or people attempting to use Maven, actually traffic this list. It would probably be more instructive to have your rant and my answers in a place where more people can see them. Would that be OK? On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have
[Repetitive]: Maven does not live up to its promises
First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. beginning of rant However, I want to give a concrete example of just why I dislike maven (and all other XML solutions) so far. I am trying to do what I think should be a reasonably easy thing to do--upload onto github (or something similar) current documentation for the project I have hosted on github. So far the best solution I've seen involves making another branch of my project and including the documentation there. This is fundamentally wrong (the docs are _part_ of the project), but I'm not blaming maven here. It's probably a git thing I don't yet understand. However, once we get past that, the pom files necessary to upload the docs are daunting, to say the least. Even more than that, though, the pom files are fundamentally unreadable. Oh I don't mean you can't puzzle through them in an afternoon or so if you have the time. Of course you can. But (and I think this deserves to be in caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not an opinion. I just don't get how people can be so oblivious to this. Would you really want to program in a dialect of XML? How many people do you know who do so? Do you really think that all of the work that has been done on parsers and compilers over the last thirty years has been in vain because, realistically, humans should just program in XML? I open up an XML file, and unless I'm quite familiar with the dialect of XML in use, simply understanding the structure takes at least half an hour. THEN I need to understand the content. There is too much redundancy, too few structural cues to indicate meaning, too few keywords (yes, they're important!), too much nesting, too little ordering in that nesting...I could go on. Of course people will dispute this. They're wrong. If they were right, we would have had something like XML for all our programming needs twenty years ago. Sorry people, you're just plain wrong. Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud over the years (and a rewrite _like_ maven was probably necessary to clear this out), but makefiles are, at their core pretty simple. You have a build target. It depends on other build targets. You build those other targets, and then you build what you're working on. Is this revolutionary? 1-b) I've mentioned this before, but Prolog has been doing declarative programming for years. Without obscure semantics. With lots of extra expressive power, like list manipulations, arithmetic, etc. etc. With an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? 2) XML is standards based. 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. All of these languages are standards compliant until they're not. XML will suffer the same fate. 3) XML makes it easy to interoperate with other systems. 3-b) This is the biggest piece of bullshit I've ever heard. It totally confuses a data format (let's say, ASCII) with a data standard (let's say, CORBA, though that's stretching things.) XML is a data format, pure and simple. No matter how hard it tries (remember DTDs?), it cannot attain the status of a data standard, because the needs of data standards evolve and continually require new things. So a data format such as ASCII, can have quite a long life--but trying to do the same thing to a data standard is a pointless exercise, and will not hold. 4) Apache is wedded to XML. 4-a) This one really pisses me off because I suspect it's absolutely true. I believe that Apache has a large number of very talented programmers, and I believe they are, in large respect, wasting their time because they have come to worship XML. I don't get it. There are things for which XML is appropriate. There are also so many things for which it's not, that why would you spend all of your time there? I don't have an answer. Anyway /end of rant Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote: First, note that I did tag this as repetitive: You don't need to be reading it if you don't want to be rehashing recent issues. You might feel better now, but emailing future such works to file:/dev/null or articulating it to your dog might be a better use of everyone else's time. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
On 23 Oct 2010, at 11:15 PM, Kenneth McDonald wrote: Now, what are the claims made for (or implied by) maven: 1) That it is declaratively, not procedurally, based. 1-a) Whoop-te-do. So are makefiles. What maven pom files are declarative means in English is that the pom file contains facts about your project, nouns. If your pom files contain verbs, then you're doing it wrong. The verbs, or what maven knows how to do, should be embedded within plugins, not shoehorned into the pom file. For examples of maven used correctly, download some of the maven plugin projects and see the way they're put together. Regards, Graham -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? I didn't say it before (saved as draft)... but I'd encourage you to create this Prolog-based build system in your free time over the next few months [perhaps use the time you'd otherwise be writing rants about Maven, you'll have it built in no time :)] and if the community decides it is a superior system for building Java (and other language) applications, the forces of natural selection and evolution will win out and Maven will die a quiet death at the hands of your Prolog-builder. PS- What's the fascination with Prolog? Do you own patents in Prolog and get paid every time someone compiles or runs a Prolog application... or merely mentions it in an email? :D Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [Repetitive]: Maven does not live up to its promises
Wayne XML is one of the most widespread and flexible languages out there, accept it, move on. We could all be investing 5 years in this discussion and we wouldn't be writing code that pays our salaries. I have been using maven on at least 70 java projects succesfully and now is a nightmare for me to work on a project without a pom.xml file. regards, Néstor Boscán On Sat, Oct 23, 2010 at 5:29 PM, Wayne Fay wayne...@gmail.com wrote: an understandable syntax. With lots of extra libraries. Would it have really been so bad to base a declarative codebase on Prolog, a mature, proven technology? I didn't say it before (saved as draft)... but I'd encourage you to create this Prolog-based build system in your free time over the next few months [perhaps use the time you'd otherwise be writing rants about Maven, you'll have it built in no time :)] and if the community decides it is a superior system for building Java (and other language) applications, the forces of natural selection and evolution will win out and Maven will die a quiet death at the hands of your Prolog-builder. PS- What's the fascination with Prolog? Do you own patents in Prolog and get paid every time someone compiles or runs a Prolog application... or merely mentions it in an email? :D Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
