Well, just to make it concrete, I am not a troll. I've been doing dev for 20+ years, have lots of experience with large projects, etc. etc. If I have to drop names, I was associated with one of the two main sites of the Human Genome Project.
I still don't get the complacency at the XML swamp. How is <genericTagName>false</genericTagName> possibly better than <genericTagName>false</> which would in turn be better than: genericTagName = "false" XML is a swamp of undertulized, overused redundancy. Period. In response to the person who'd interrogated 2K+ people to see if they thought XML was overrdone; Wow, that's really impressive! Where did you find the time to ask all those people and still get your your job done? Whereas, if I ask the five people who I know well, and who have to use these tools, the answer is, "what a bunch of garbage". They HATE XML. Still not convinced? What about the simple fact of that that languages before, and the languages _since_ have not been written in a dialect of XML. If XML were such a great solution, surely it would have cleared here by now. But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION. Period. No Line breaks. Unless one is writing for ultimate display in the web, XML SUCKS In all the best to have all the people who have responded to this, I don't see how you can continue maintain your position, Yours, Ken On Oct 15, 2010, at 8:27 AM, Yanko, Curtis wrote: > +1 > > ________________________________ > > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT > Making IT Happen, one build at a time > > -----Original Message----- > From: Brian Smith [mailto:[email protected]] > Sent: Friday, October 15, 2010 5:39 AM > To: Maven Users List > Subject: Re: maven is a swamp > > I really fail at understanding the XML rage. Yeah it's verbose. How's > that a problem? We've had tools with auto complete, auto format and > syntax highlighting for well over a decade, we also now have fairly > robust GUIs too. If you're hand editing a 2000 line xml file in a green > screen terminal you're doing the equivalent of using an abacus and I'm > afraid you're not the user new tools ought to be aimed at. > > XML has a huge ubiquity value. It might not be the *best* tool for the > job for each individual user but it's the only one that is widely enough > understood to not put an additional learning burden on the user. When I > learned Maven I had to grok concepts like dependencyManagement and > plugins and phases. I didn't have to learn XML, I already knew it. If > Maven POMs were written in Python or A.N.Other language/markup I'd have > to learn that too. There are many useful libraries that make it easier > to produce GUI tools on top of XML that don't exist for alternatives, so > we'd have less tooling for POMs. Tooling and minimising the learning > required are good things. > > The _actual_ problem I see is the lack of "best practise" use for > plugins off the beaten track. The documentation is usually fairly good > at telling you how to make a plugin do something, it's less than > brilliant at recommending best practises and unless it's one of the > mainstream ones covered by the sonatype book it's hard to find. I've > found the best thing to do in those cases is go look at large, open > source projects and see how they do it. Ken's original problem in this > thread (and the others he's been getting help with on the scala list) > are _nothing_ to do with XML, that is just the target of frustration. > They would have happened regardless of the language for POM > specification. > > For us, Maven's killed about 12,000 lines of ant legacy built up over a > few years, and also done a drive by on a couple of dozen ivy files, > replacing them with one medium size POM declaring dependency versions, a > dozen small ones declaring dependencies, and a bunch of minimal ones - > all with NO bespoke build instructions in. Using nexus has killed the > need to maintain an internal ivy repository which was a real pain in the > rear, and we can now easily share deliverables with the other couple of > hundred developers we have working in the same technologies around the > globe. It's been very painless by comparison to what we were doing > before and well worth the switchover. > > Regards > > Brian > > On 15 October 2010 08:56, <[email protected]> wrote: > >> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote: >>>> A fact to note though is that I've asked over 2k people over the >> last two years at talks and in any average crowd the people who care >> to have a different format or DSL is around 3%. >> >> And I one of them :-) I always havent been a friend of XML and I happy > >> to see the possibilities maven3 offers (although I prefer using gradle > >> - >> bygones) >> >> What I'm wondering most is - why the heck do you write to the maven >> mailinglist how you dislike maven ? Is your intention to convince >> people that they are doing bad stuff over the last xxx years ? Is it >> just pure boredness ? >> >> I dont like Ruby or Clojure - what is the reason to bother the >> ruby/clojure mailing list that their syntax is apparently horrible ? >> >> Sorry - I dont get it... If you dont like maven - dont use it... there > >> are tons of alternatives around. >> >> Or what point do I miss here ? >> >> >> > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified > that any dissemination, distribution or copying of this e-mail is > prohibited. If you have received this e-mail in error, please notify the > sender by replying to this message and delete this e-mail immediately. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
