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. >> >> >> 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
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
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
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
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. >> >> >> 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 >> sta
[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. 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 Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to push doc pages to github via maven?
Many of you will know me from the "Maven is a swamp" thread :-) I don't disagree with that, but I am willing to concede that maven can be used to do some very powerful thing--in the right hands. I fear, those hands are (not yet) mine. Here is my problem. I have a library (an OO wrapping around regexes) which I think is pretty useful. I have it up in github, but of course for anyone to be convinced, they need to download it, build it, yada yada. A lot of work for a questionable payoff. I'm not going to attract a lot of converts that way. However, I've also got a lot of documentation (and am always adding more) to show the benefits of the library. If I could get this out in front of people's noses, I might be able to attract more attention. I would like to do this with maven and gh-pages, but have not got a clue where to start. If you could recommend some reading, I'd be most appreciative. I'm not looking to have my hand held, just a reasonable starting point for this task. Thanks, Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
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 false possibly better than 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:bmjsm...@gmail.com] > 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, 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 pu
Re: maven is a swamp
On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote: > Hi Kenneth ! > > Drawback of using a Python/YAML like solution is code completion. > But the payoff is you don't need code completion! You just put in a )/}/] or so, and your code is completed! Any yes, any competent text editor can check for braces mismatches etc. I recognize the concern, I just don't see it as valid. I've been programming in Python for twenty years now. I won't say it's always the case, but in a large number of cases, the terseness you gain in your code more than offsets things like code completion, static analysis, etc. And yes, I specifically intend this to apply to XML. I can't see how moving to a YAML model would be anything but a win for maven. Just to let you know I'm not firmly entrenched in one camp, the static analysis that Scala supplies seems to me to overcome the inherit "benefits" of dynamic analysis. Ken - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
>> Hi Wayne, I'll post one more response to your well-thought-out question.
>>
>> Here is the pom file I'm currently using:
>>
>> and just so you don't have to scroll all the way to the bottom to see the
>> comments, I'll put them here :-)
>>
>> - Is there _anything_ in the structure of this file which leads me to an
>> "aha, I understand what the major
>> and minor parts of the file are all about" moment?
>>
>> - Does the file get across what it means both concisely and clearly?
>>
>> - Is the syntax of the file for the convenience of the programmer, or the
>> convenience of the tools
>> that process it?
>>
>> - Could someone well-versed in programming, but without an understanding of
>> maven, make at
>> least some sense of this file?
>>
>> IMHO, the answers are no, no, for the convenience of the tools, and no. In
>> terms of readability,
>> this file (and all pom files I've seen) are simply disasters. In terms of
>> semantics--OK, pretty good.
>> In terms of usability, what a piece of garbage!
>
> But why would you ever see this?
> Doesn't your IDE support Maven?
I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes me
look at the pom as xml. But
even that begs the question.
> There is no reason why any of my guys would ever look at this as XML.
> We use Eclipse/STS as an IDE and this simple POM would never require anyone
> to do anything in XML.
>
> Hand editing POMs is not a reasonable thing to do in 2010 unless you are
> debugging Maven and want to break a POM to see what Maven does.
>
I agree. Hand editing POMs is not reasonable because POMs are not amenable to
hand editing. That's a problem
of the POM format, not of the concept of hand editing.
> You need to look at parent POMs to get rid of the clutter:
>
> This goes in the project parent POM so you don't put it in a POM that
> generates an artifact:
That may be the case (and is something that is nonobvious from reading basic
maven docs), but...
>
>
>
>kmcdonald
>Kenneth McDonald
>ykkenmcd [at] gmail com
>
>
>
>
>
>Lesser General Public License (LGPL)
>http://www.gnu.org/copyleft/lesser.txt
>repo
>
>
>
developers = [{id: "kmcdonald", name: "Kenneth McDonald", email: "ykkenmcd [at]
gmail com"}]
licenses = [
{
name: "Lesser General Public License (LGPL)",
url: "http://www.gnu.org/copyleft/lesser.txt";
distribution: "repo"
}
]
That's ten lines of code vs. fifteen, and the ten lines are _much_ more
readable. And I could've compressed those ten lines further without much
effort. C'mon, people, where's your sense of proportion? The syntax I've used
is pretty Pythonic (not sure if it's exactly that since I've used
Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_
time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the
problem with using a syntax that is:
a) easily parsed
b) easily read
c) easily written
Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that
things should be text _unless_ they are explicitly marked as not text. This
completely flies in the face of I don't know how many years of CS, and is
simply wrong. Most of most coding constructs is control logic. It follows that
it should be easy to write the control logic, a little bit more difficult to
write the literals. Now when HTML was being designed, that was different,
because they were designing to a format whose primary purpose was visual
represention on a page. Guess what, boys and girls--we're not doing that
anymore! XML is a control format, and should make it easy to write the control
parts of the statements, and a little tougher to write the literal parts. The
fact that it doesn't do this is evidence if its almost complete inadequacy to
serve as a control language.
...I've edited out a lot here below for brevity.
Cheers,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:
> As much fun as all this commentary is, unless Ken comes back and posts
> a reply, I feel like we're simply the victims of a drive-by
> trolling...
>
> As such, I recommend letting this thread die, at least until Ken comes
> back and adds something to the discussion... Ken???
>
Hi Wayne, I'll post one more response to your well-thought-out question.
Here is the pom file I'm currently using:
and just so you don't have to scroll all the way to the bottom to see the
comments, I'll put them here :-)
- Is there _anything_ in the structure of this file which leads me to an "aha,
I understand what the major
and minor parts of the file are all about" moment?
- Does the file get across what it means both concisely and clearly?
- Is the syntax of the file for the convenience of the programmer, or the
convenience of the tools
that process it?
- Could someone well-versed in programming, but without an understanding of
maven, make at
least some sense of this file?
IMHO, the answers are no, no, for the convenience of the tools, and no. In
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!
So I guess my comment is, decent internals, horrible externals.
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ykken.rex
rex
0.5-SNAPSHOT
2010
kmcdonald
Kenneth McDonald
ykkenmcd [at] gmail com
Lesser General Public License (LGPL)
http://www.gnu.org/copyleft/lesser.txt
repo
2.8.0
scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases
snapshots.scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases
org.scala-lang
scala-compiler
${scala.version}
org.scala-lang
scala-library
${scala.version}
junit
junit
4.8.1
test
org.scalatest
scalatest
1.2
test
src/main/scala
src/test/scala
org.apache.maven.plugins
maven-dependency-plugin
2.1
org.scala-tools
maven-scala-plugin
2.14.1
compile
testCompile
org.apache.maven.plugins
maven-surefire-plugin
2.6
false
**/*Test.*
**/*Suite.*
org.scala-tools
maven-scala-plugin
2.14.1
org.apache.maven.plugins
maven-dependency-plugin
2.1
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote: > As much fun as all this commentary is, unless Ken comes back and posts > a reply, I feel like we're simply the victims of a drive-by > trolling... > > As such, I recommend letting this thread die, at least until Ken comes > back and adds something to the discussion... Ken??? Sure, happy to. I won't be quite as angry in this post as in the last one :-), but I still have a lot of complaints against the Maven way of doing things. I won't hit them all, here are a few random thoughts: 1) Maven is declarative vs. procedural. This is great, but Prolog has been that way for decades. Why build such a complex syntax when a much simpler one already existed. 2) Relates to 1). I still think this is important. AFAIK, XML was NEVER intended to be a syntax for direct editing by the user. It is needlessly verbose and redundant, and seriously obscures the actual intent of the code. As the simplest possible example, what is the point in writing false when what is really meant is the (IMHO) much easier to read someGenericOption = false. 3) Yes, I'm aware there is something called polyglot maven. (Haven't looked at it yet, as I don't want to add yet another layer of complexity to what I'm doing.) Doesn't the simple existence of this prove my point? There were never polyglot makefiles--in spite of all of their (numerous) problems, the syntax of makefiles was simple enough there was never a demand for them. 4) Maybe I'm missing something, but maven seems to be all about predefined maven tasks. (Not sure I'm using the right terminology). If there's something simple I can do from the command line, maven doesn't provide an obvious way for me to do it. 5) Maven is just too complex. The comment I've seen is, "If users would just read a book...", but what if I don't have the time to read an entire book simply to figure out how to push my docs to github? With command-line access, I wouldn't need to do so. And if the project got so big that an ad hoc solution didn't suffice, _then_ I could come back and read the book. So those are just a few random thoughts. Make of them what you will. Thanks, Ken > > Wayne > > On Wed, Oct 13, 2010 at 5:13 PM, Rick Mangi wrote: >> Flexible and elegant aren't necessarily the same thing... Any language that >> prides itself on its ability to be obfuscated can't be elegant ;-) >> >> That said, I do love it. >> >> As far as Maven goes, the elegance of maven is that it does 90% of what you >> need it to do with very little or no effort and the other 10% can be done >> without much hassle. >> >> >> On 10/13/10 10:48 AM, "Kathryn Huxtable" >> wrote: >> >>> It does. The rest of the language is rather ugly, though. -K >>> >>> On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote: >>> I just enjoyed the bit about perl having elegant and concise data structures :-) >> >> >> - >> 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 > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven is a swamp
Yes, I realize this is flamebait, but after trying to puzzle out the following maven plugin: maven-antrun-plugin 1.6 deploy deploy-gh-pages run I simply can't resist. Whoever in their right mind decided software developers to think that requiring other developers to write config files in XML was a proper decision? Python, Ruby, and (yes even Perl) have had had much more elegant and concise ways of managing complex data structures for years now. And there's a reason JSON has become so popular--primarily because XML is not, and was never intended to be, a format for developers to write specifications in. Let's take a look at the most obvious of the problems in the above: Now, I'm still very new to maven, but it strikes me that what the above is saying is (in Pythonic code, but feel free to convert to your own): import git gh-pages-dir = "" git(dir=gh-pages-dir, "add .") git(dir=gh-pages-dir, "commit") git(dir=gh-pages-dir, "push origin gh-pages") I'm sure there are errors in the translation--but I'm equally sure that if these errors were corrected, they would not substantially alter the ratio of XML to Pythonic code. Ruby and even Perl would do just as well. So here's a challenge to the (very intelligent) folks at apache. Open your minds to the fact that XML is not only the Final Solution, but isn't even close to the best solution, and start producing some products that are configurable without an entire manual in front of oneself. I realize that arriving at an optimal solution is not really possible, but XML is so suboptimal as to beggar belief. I am just so sick of using crappy "solutions" (read: XML) layered over top of what could be good solutions. Sorry, had to vent. Who knows, maybe it'll do some good? Ken McDonald - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Solution to scalatest "test" phase under maven
For some reason, the message below didn't get sent to the scala users or maven users list--at least, not as far as my inbox is concerned :-) So I'm sending it again, in the hopes of helping people who might find themselves in the situation I was in. Sorry if this is a repeat in your mailbox. Ken > > Posting this in hopes it will help others. First, I'd like to heartily thank > everyone who gave of their time with helping me in this problem. I learned a > log about maven (more than I really want to :-) but it's good for future > jobs), and I wouldn't have found the solution on my own without a _lot_ more > time. > > Basically, a couple of people sent me pom files which worked for them, but > which didn't work for me. I don't know why, this is still a mystery. What did > work was the following highlighted line: > > >org.apache.maven.plugins >maven-surefire-plugin >2.6 > >false < > >**/*Test.* >**/*Suite.* > > > > > I'm going to have to dig into the Maven documentation and refresh my memory > of manifests (its been _years_ since I've used Java) to figure out exactly > what is going on, but once I added this, my tests ran smoothly. (And I am > happy to say, all are still OK :-) ). > > Again, many thanks to all, > Ken McDonald - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Solution to scalatest "test" phase under maven
Posting this in hopes it will help others. First, I'd like to heartily thank everyone who gave of their time with helping me in this problem. I learned a log about maven (more than I really want to :-) but it's good for future jobs), and I wouldn't have found the solution on my own without a _lot_ more time. Basically, a couple of people sent me pom files which worked for them, but which didn't work for me. I don't know why, this is still a mystery. What did work was the following highlighted line: org.apache.maven.plugins maven-surefire-plugin 2.6 false < **/*Test.* **/*Suite.* I'm going to have to dig into the Maven documentation and refresh my memory of manifests (its been _years_ since I've used Java) to figure out exactly what is going on, but once I added this, my tests ran smoothly. (And I am happy to say, all are still OK :-) ). Again, many thanks to all, Ken McDonald - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problems with Scala unit testing
Thanks for the advice, unfortunately those things did not cure the problem. I must admit, I'm very puzzled. More experienced maven users seem to have run out of ideas as well, so I may have to look at a different solution for running my tests, which is very unfortunate. Thanks, Ken On Sep 27, 2010, at 9:12 AM, Nayan Hajratwala wrote: > On Sep 26, 2010, at 3:47 PM, Kenneth McDonald wrote: > >> >> Now for a run of mvn test: >> >> mvn -X test >> . >> . >> . >> [INFO] Surefire report directory: >> /Users/Ken/mvn_projects/rex/target/surefire-reports >> Forking command line: /bin/sh -c cd /Users/Ken/mvn_projects/rex && >> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java >> -jar >> /var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefirebooter1692256912894030002.jar >> >> /var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefire9017473591909367701tmp >> >> /var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefire6246108229640345050tmp >> org.apache.maven.surefire.booter.SurefireExecutionException: >> scala/ScalaObject; nested exception is java.lang.NoClassDefFoundError: >> scala/ScalaObject >> java.lang.NoClassDefFoundError: scala/ScalaObject >> at java.lang.ClassLoader.defineClass1(Native Method) >> . >> . >> . >> >> The point here is that scala-library is nowhere to be seen. I don't know if >> maven puts into one of the tmp directories (that would seem odd), but my >> guess is that there should be some mention of scala-library on the command >> line, but there isn't. > > I ran mine with -X as well, and the scala-library does not show up on the > classpath, so that's not your problem. > >> >> And here's my pom.xml file. AFAIK (I'm just learning maven), this should >> mean that scala-library is a dependency across all phases: >> >> http://maven.apache.org/POM/4.0.0"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> http://maven.apache.org/maven-v4_0_0.xsd";> >> > > [snip...] > >> >> >> snapshots.scala-tools.org >> Scala-Tools Maven2 Repository - Snapshots >> http://scala-tools.org/repo-snapshots >> >> > > Why are pointing at the snapshot repo for plugins? Since you're new to maven, > you may or may not be aware that SNAPSHOT means the current development > release, i.e. trunk. In general, you'll want to use release versions of third > party libraries. > >> >> src/main/scala >> src/test/scala >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> 2.1 >> >> >> org.scala-tools >> maven-scala-plugin >> 2.14.2-SNAPSHOT > > Why are you using the SNAPSHOT versions of the plugins? You should be using > the latest release, which is currently 2.14.1. This *might* be your problem. > >> >> org.apache.maven.plugins >> maven-surefire-plugin >> 2.6 >> >> >> **/*Test.* >> **/*Suite.* >> >> >> >> >> >> >> >> >> org.scala-tools >> maven-scala-plugin >> 2.14.2-SNAPSHOT >> >> >> org.apache.maven.plugins >> maven-dependency-plugin >> 2.1 >> >> > > You probably don't need anything in the reporting section. > >> >> >> >> > > > --- > Nayan Hajratwala > http://agileshrugged.com > http://twitter.com/nhajratw > 734.658.6032 > > > - > 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
Problems with Scala unit testing
Hi all,
First of all, just for those that aren't familiar, Scala is one of the family
of languages that compiles to JVM bytecode. Arguably the most sophisticated of
them.
I can't run my Scala unit tests with Maven (the unit test suite I'm using uses
JUnit), and I think I know why, but I don't know how to solve the problem.
First, let me show you the output of the maven compile phase, using DEBUG
output, which does run correctly:
mvn -X compile
.
.
.
[DEBUG] cmd:
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java
-classpath
/Users/Ken/.m2/repository/org/scala-lang/scala-library/2.8.0/scala-library-2.8.0.jar:/Users/Ken/.m2/repository/org/scala-lang/scala-compiler/2.8.0/scala-compiler-2.8.0.jar:/Users/Ken/.m2/repository/org/scala-tools/maven-scala-plugin/2.14.2-SNAPSHOT/maven-scala-plugin-2.14.2-SNAPSHOT.jar
-Xbootclasspath/a:/Users/Ken/.m2/repository/org/scala-lang/scala-library/2.8.0/scala-library-2.8.0.jar
org_scala_tools_maven_executions.MainWithArgsInFile scala.tools.nsc.Main
/private/var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/scala-maven-548486675003034.args
[INFO] prepare-compile in 0 s
[INFO] compile in 11 s
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
The point here is that scala-library is on the classpath.
Now for a run of mvn test:
mvn -X test
.
.
.
[INFO] Surefire report directory:
/Users/Ken/mvn_projects/rex/target/surefire-reports
Forking command line: /bin/sh -c cd /Users/Ken/mvn_projects/rex &&
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java -jar
/var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefirebooter1692256912894030002.jar
/var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefire9017473591909367701tmp
/var/folders/J6/J6Md7QzoH-apMu-1gFqvaE+++TM/-Tmp-/surefire6246108229640345050tmp
org.apache.maven.surefire.booter.SurefireExecutionException: scala/ScalaObject;
nested exception is java.lang.NoClassDefFoundError: scala/ScalaObject
java.lang.NoClassDefFoundError: scala/ScalaObject
at java.lang.ClassLoader.defineClass1(Native Method)
.
.
.
The point here is that scala-library is nowhere to be seen. I don't know if
maven puts into one of the tmp directories (that would seem odd), but my guess
is that there should be some mention of scala-library on the command line, but
there isn't.
And here's my pom.xml file. AFAIK (I'm just learning maven), this should mean
that scala-library is a dependency across all phases:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
your.proj.gid
rex
1.0-SNAPSHOT
2010
2.8.0
scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases
snapshots.scala-tools.org
Scala-Tools Maven2 Repository - Snapshots
http://scala-tools.org/repo-snapshots
org.scala-lang
scala-library
${scala.version}
junit
junit
4.8.1
test
org.scalatest
scalatest
1.2
test
src/main/scala
src/test/scala
org.apache.maven.plugins
maven-dependency-plugin
2.1
org.scala-tools
maven-scala-plugin
2.14.2-SNAPSHOT
compile
testCompile
org.apache.maven.plugins
maven-surefire-plugin
2.6
**/*Test.*
**/*Suite.*
org.scala-tools
maven-scala-plugin
2.14.2-SNAPSHOT
org.apache.maven.plugins
maven-dependency-plugin
2.1
Thanks,
Ken
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
