After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool.
Reflecting on my history with a UNIX shell going back to the late 80s, I realized that things I had learned 10, 20 years ago from the UNIX world were still relevant today. I committed myself to getting serious about vim because I want to optimize for A) learning many programming languages and B) not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring.
While this kind of toolset will never provide quite the bang for the buck of a contextual IDE in a specific language, it's a phenomenal hedge against all the career risks I face in terms of Ruby becoming irrelevant, the web becoming irrelevant, Apple nerfing OS X, or any other probable sea change. No matter what happens I feel like vim + bash will bring me an immediate level of productivity in any new task I face, even if I start flattening out before I reach the Eclipse or Visual Studio level of wizardry, I don't expect any one thing to last long enough in this industry for such optimizations to pay off.
You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio.
Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwdriver over a drill.
Collections.sort(myList, new new Comparator<E>() { public int compare(E o1, E o2) { return 01.val-02.val } }
(You could also make your class implement Comparable, but then you need to own the class, have only one ordering used in the entire program, not mind making the ordering a property of the class).
If you are in an IDE, then writing all that out is not to bad because of auto complete. If you are stuck in a plain-text editor, you would much prefer something like: Collections.sort(myList, lambda<E->int> x->x.val);
Java 8 does incluse lambda's, so maybe this particlar case has been solved. But languages with a strong CLI pressense in the community tend to need alot less IDE than languages with a strong IDE pressense in the community.
All analagies suck, but let me just refine this one by saying that the unix philosophy is like preferring a toolbox with a screwdriver, a wrench, a saw, a hammer and other simple tools vs a power drill—the power drill is great for driving screws but it's completely useless for other tasks, and it won't necessarily fit into tight spaces that a small screwdriver would.
Opening a file and reading from it takes tens of lines in Java, and that's just a trivial task. Stuff like that is better left auto generated.
You don't learn Java these days, you just learn eclipse. Much of the magic is happening in auto complete. I am not sure who picks up a book to learn java these days.
But if I'd insisted on sticking with Emacs instead of moving in the mainstream (Xcode & IntelliJ for mobile) I would have ultimately been much less productive than I've been after spending a week getting my head around more specialized tools.
My brain-stem knows what to type when I want to go to the end of the line. If the tool doesn't do what I expect when I hit that keystroke, I update the keymapping. In about 1 hour of coding/retraining, the keymap works quite well.
Best of both worlds
I install a vi plugin anywhere I can. Most of the time this bridges my mental gap. There is nothing worse than a half working vi plugin though.
Recently, I inherited a project that had 10,000s of lines of ant scripts. Resource constrained, I didn't have anyone to maintain that build process. So, I took a few hours and converted those projects to several hundred lines of maven 'scripts'. Now, it works way better than the previous system, because now I can have a person focused on coding features, rather than maintaining process.
Maven was what I knew at the time; and, it fit well enough. Maybe Grails is the right answer, though. Or, something else.
Anyway, ultimately, it comes down to what trade-offs we make and what things we prioritize with our limited knowledge that we have available. And, that is the art of software development.
The poster probably means gradle. I am not pointing this out to be pedantic, but because it's not a given that every reader will know their way around the universe of build tools.
Do you really need stupidly concise code in a build process that gets updated .01% of the time compared to the rest of a project? I'd rather have the verbosity and formality (Maven plugin vs. customized groovy)
But he is absolutely correct about the key observation: a basic tool with "plugins" is simply NOT the way to create a build tool. A built tool should allow (when needed) the full flexibility of a Turing complete programming language. Because eventually your project is probably going to need it.
Your plugin has to play by the rules, which is a good thing.
Maven's useful for more than the beginning of a project. If you're working on real-world software, you're probably not the only person who has to understand your bespoke build, if that's the way that you've chosen to go.
A built tool should allow (when needed) the full
flexibility of a Turing complete programming language.
Because eventually your project is probably going to need
it.
OR
You're reading a file and using the details in that file to control your build.
OR
You need to loop through a set of properties and apply a specific update to each value before the build.
OR
You need to invoke complex build logic based on the platform you're building for (nested ifs).
etc.
There are lots of odd situations you end up in with real projects.
The flexibility this provides comes at the cost of build complexity though.
Obscure syntax and odd custom DSL's (>_> cmake, make, powershell) are bad because they introduce complexity and destroy the readability and maintainability of the build.
You basically need a test suite for your build code to make sure it's building correctly. Terrible.
...but, necessary. I'm not a java guy, but writing C and C++? You need to do this stuff all of the time. scons or cmake really make life a lot easier than trying to force Makefiles to do things with their obscure lambda syntax.
It uses the groovy language so hopefully it doesn't fall into the same trap as described in the post.
It's something about the dependency resolution mechanism. Something is broken, but I haven't been able to pin-point it yet.
It's frustrating because I love Groovy. I write a lot of Groovy and I'd love to use a Groovy-based build tool, but I can't justify wasting a lot of time on Gradle when I know how to do what I need to do in Maven.
The article mentions Gradle :-P Need to read the whole article ;-)
If it has it, someone is going to think they need it. A year later you have 10,000 lines of Ant and nobody to maintain it.
Building code is not hard. Discipline is hard.
My only fear with maven is when things break or someone how you have a wrong version of maven that the script requires or downloads fail or something else. If the script fails you can't do anything. And who knows, the only that was required was just compiling the java source with minimal dependencies.
Then you would just type mvn assembly:assemble
Anyway, you have three levels of builds.
- Complex Perl scripts, bash/unix scripts : these people are insane and generally have degrees in physics and mathematics. They write scripts that are unreadable, can't modify, are cryptic and I imagine that that the authors can't read them. I sometimes see these in old Linux programs.
- Complex Make, Autoconf, bash/unix scripts : A little better than the perl build scripts but still a complex because you have to understand each command used. I am not fan and never was a C/C++ developer. I guess these are still used in the non-Java world. I am looking at you 'OpenJDK/Sun JDK'
- Complex Ant scripts : These aren't bad, easy read, a little bit difficult to maintain over time. I think most developers prefer Maven but don't mind an Ant script if the project is small
- Maven Scripts : I think people use maven because not much else exists. And the problem of compiling code is not that serious as the actual application development.
I looked at maven a couple time but could never figure out how to convert a make-based build to maven because there is always a bunch of weird hacks lurking in the makefile. However, I do see how maven would be fine for a new project.
And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to do it. You may think you need to do it, you probably don't. Maybe what you need is a more powerful deployment system, or something that takes over after your java/scala/whatever is built.
If you're building perl, C, C++, sure, maven isn't going to do it for you. If you're building java, you're sorted.
My favorite is when this sequence happens (I have seen it first hand):
1. Maven is this external system that we have no control over.
2. We will write our own system that will be awesome.
3. Wow, look, every project uses our Build System!
4. Oh, look, someone on project X changed B.S. and now Projects A-N don't work!
5. We will lock down B.S. so only the one person who wrote it can change it!
6. ...
7. B.S. is this internal system that we have no control over!
8. ...
9. Can we add support for merging war files?
10. No that'll take weeks, and Bob isn't available anyway.
I work in a java shop currently. There's got to be a hundred of us. Every single one uses an IDE.
When I use maven, my IDE just works. eclipse, intellij, netbeans all support maven. Want to put a bunch of files in a common war to share? maven has a merge-war plugin and intellij and eclipse know what it means: they both build projects that copy the files just like maven would do. Better yet, as you edit those files, no matter where they are, both eclipse and intellij update the files in the deploy target and they are available when you refresh your browser. There is a huge amount of investment in making this stuff work. This is convention over configuration.
No tool can do this with Ant (or Ruby) unless it runs the Ant and the Ruby, and then you've side stepped the IDE and reduced them to dumb text editors. With an Ant project, the IDE can't know that when I edit file A, it is transmogrified into file Z. (If it could, it could solve the halting problem). With Maven, the IDE implements convention, and so it know that File A is compiled to File B and then must be copied to location Z because its part of a merged war. Add JRebel to the equation and pretty much any change to the code is immediately runnable. Its dangerously easy to spike away instead of writing tests!
Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable:
- submitting code to a code review site like Gerrit.
- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).
- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).
- code coverage analysis (yes, there's a Maven plugin. You ever used it?).
- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).
- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things.
- C code (through JNI or anything else, a perfectly reasonable thing to want to do).
- deployment.
From bitter personal experience it is possible to get so wrapped up in this that you think you have achieved something amazing when you finally finish, when it could have been done in a few hours in make or rake.
"Oh, but you can integrate it with your IDE!" The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests. Everything else they do with command line calls, just like it was Ant.
Have you looked at http://maven.apache.org/guides/introduction/introduction-to-...?
Maven is particularly good at generating code for later compilation and processing. Your custom code generator just needs to put code into src/generated and it will be picked up.
Given that Maven is used to organize and build some pretty large projects out there in the real world, you might want to amend your statement from "Maven scales astoundingly poorly" to "I am astoundingly poor at scaling Maven".
It's not all wine and roses in the land of Maven, but it gets a whole lot of the job done, and done well.
The original article was helpful to clarifying for me why I have such a low opinion of maven - the project I was working on when Maven came out was a large complex codebase and we'd built lots of interesting things into our Ant build files. I could not work out how to ever do those sorts of things in Maven.
Why would you want your build tool to do that?
>- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).
There are plenty of plugins to do that. If you want one that doesn't exist, write your own. It's not hard, and means this operation will be encapsulated in a structured, testable, reusable way. If you're generating code in an ad-hoc, specific-to-a-single-project way, you're doing it wrong.
>- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).
Yep, I've used it. It works fine.
>- code coverage analysis (yes, there's a Maven plugin. You ever used it?).
Yep, I've used it. It works fine.
>- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).
Yep, I've used it, it works fine.
>- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things.
Huh? You can depend on a specific version, a range of versions, or a range with gaps in. You can't depend on two versions of the same library because it's impossible to set the classpath up like that, but that's a limitation of Java, not maven.
>- C code (through JNI or anything else, a perfectly reasonable thing to want to do).
There are ways to do this, I'll agree it's not pretty. If you want to use another build tool for those projects that include C code that's fair - it should be a minotiry of your projects.
>- deployment.
Not the appropriate tool for it.
We use Maven and it just works. We play with the idea to move to Gradle, but the effort is non trivial and the real benefits not clear.
We use Sonar. We use Clover for code coverage. We use PMD. We use Checkstyle. We use FindBugs.
- code coverage / findbugs etc. are better done using something like Sonar. Again, this works just fine for us. You can also set up Sonar & Jenkins on your desktop in minutes and have a working analysis suite + web interface without centralising your builds.
And I assert that you're wrong on the IDE integration - Intellij appears to shell out to Maven for some things, but M2E in Eclipse is a completely different beast (and has some rough edges as a result, but can work well).
This seems like a java problem more than a maven problem. In fact, I don't really know what you could do about this. Maybe OSGi has a solution.
And how does it get that from ant? That seems such a small thing. "Everything else they do...." must be so important. I don't think it is. I think the most important thing is that when developing in the IDE I have a reasonable certainty that when it builds on the CI server that its going to do the same thing. The next most important thing is that our team can develop using the IDE each prefers (or vim if they want). Maven is the only "project description" that is understood by every IDE and also runs from the command line.
"Everything else they do with command line calls, just like Ant".
Not so. For example, both eclipse and IntelliJ, when faced with a merge-war project, will set up a project definition that provides the same behavior as running maven, but without running maven. Modifying a resource in the common war project causes that file to be deployed to any running targets. Its instantaneous and automatic. Its the difference between an Integrated Development Environment and a text editor.
Everything else, don't use maven. Maven is a tool for building java.
Our tools for deployment make maven look like "hello world". I wouldn't use maven to deploy. Likewise for submitting code to anything. I use maven to build deployable targets from java and to upload them to a repo. End of story.
Basically, if it hurts when you do that, don't do that. I use bash on my build server. Somewhere in the middle, bash runs maven.
So how would I handle generating some code from another format? Depends what it is. One fellow said reading from a database for example. Well before I ran maven, I'd run the program that generated the java files, and then I'd check those files into source control so that we know what exactly got built. Then I'd run maven. If it was generating java from a text file, I'd probably have it as an Ant task in my IDE, and whatever got generated, I'd check that in too. Sometimes I've gone as far as to write an IDE plugin that builds the file automatically.
Checking in generated files? Isn't that an excuse? Well, no, not if you want to guarantee to be able to build it in 18 months time. I've worked at a place where they couldn't even build an 18 month old product to support a customer because the build system itself wasn't versioned!
e.g. take this selenium install instructions (http://seleniumhq.org/docs/03_webdriver.jsp)
Ruby:
gem install selenium-webdriver
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="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/xsd/maven-4.0.0.xsd>
<modelVersion>4.0.0</modelVersion>
<groupId>MySel20Proj</groupId>
<artifactId>MySel20Proj</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>2.28.0</version>
</dependency>
<dependency>
<groupId>com.opera</groupId>
<artifactId>operadriver</artifactId>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.opera</groupId>
<artifactId>operadriver</artifactId>
<version>1.1</version>
<exclusions>
<exclusion>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-remote-driver</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
</project>
mvn clean installSo: you need a groupId; we've learnt through painful experience that this is a good idea to prevent collisions rather than just using the name. That said, your tool should autocomplete it if there's only one option.
You need to specify a version; this is 1000% the Right Thing. Again, your tool will give you a list to choose from.
And yeah, it's a bit of a verbose way to specify those three pieces of information; the point is for it to be easy to automatedly manipulate the pom file.
Let me illustrate what we do at work to explain. We use Jenkins as a build server and a hosted git repository. Every accepted pull request to mainline-dev is picked up by Jenkins, Jenkins runs mvn test on the commit, if the build passes, Jenkins integrates the change into mainline-stable, and Jenkins runs mvn deploy to get the latest build on a mainline-stable server.
Setting up this workflow required little customization because mvn's output was well-defined and designed to be composed within other environments, and jenkins is one common place that understands it. So are the IDEs at your work. So is the next person to tweak the environment who can look at docs to figure out what's going on. It's no different than how sed knows how to interpret tr's text output.
Does this workflow work for everyone and every language? No, not at all. Does mvn the tool work for everyone and every language? No. But I see it as an example how mvn, a build tool, fits into larger process and is a composable tool the author lauds.
P.S. The biggest benefit for our shop is twofold:
1) Dependencies get resolved automatically in all environments. Unlike my last gig, developers run the same version of libraries as the prod machines do.
2) Developers run the same test cases locally as jenkins does. We've only had one build break.
And then the person that wrote them leaves and we're fucked.
The consistency of an opinionated build tool does provide some not insignificant benefit.
Instead, you want general purpose language that builds the build dag using the build system as a library. This gets you control and customisability for free, and you can still get reuse through code libraries.
Last year replaced a maven shitfest with an old fashioned Makefile which calls javac and manual dependencies. The whole port process took about 2 hours.
Integration and test run time has gone from 7 minutes (to drag all the maven plugins and dependencies down) to just over two minutes.
This saves us a fortune on build agent capacity as well (we use TeamCity).
I am really good at make and reasonable at ant. If you cant build a java project with those then you are the problem not the build system.
Question: Maven is taking too long and downloading plugins and dependencies everytime. What should I do?
Answer:
1. Its shit! Write my own!
2. Well, that seem suboptimal. Would the smart people who wrote it have made it download all this stuff everytime it builds? Surely that is wrong. Maybe I could google that?
I've worked on countless Maven builds and have done everything under the sun. Maven's plugin system allows you to ultimately achieve whatever you need out of your build--in the 10% case that you have a need that isn't already covered by the varied plethora of plugins out there. You can even call out to Ant using the antrun plugin.
I've found so much simplicity, reliability, continued payoff in my use of Maven. I've heard complaints but usually from people that refuse to understand how it functions declaratively.
Declarative systems like Maven ask that you learn something first, and then reward you infinitely if you do; imperative systems let you do something immediately without learning a model, but then make you infinitely pay for it.
Tools like Rake and Gradle (and Buildr) are more like thin wrappers on a turing complete language and are able to stretch and bend to fit the problem. Sure, that makes them harder to get started with, but it provides much more runway when the build gets complicated.
I've used Maven in the past on some projects and it starts off very nicely. However, without fail, I end up with some part of the build that doesn't work quite right. Or throws unresolvable errors. Or just fails, some of the time. I guess I (and everyone I've ever worked with) sucks at Maven and just can't make it work. If so, that tells me much more about Maven than my team's abilities.
P.S. I (mostly) blame XML for my Mavin chagrin. Over the years I've grown to hate XML and everything associated with it. It should burn in a fiery pit of lava. But that's just me. :)
I'm not sure if it's due to someone's lack of technical ability, or if they get distracted by other externalities, but we always tend towards something that seems really simple at first but instead incurs a lot of technical and process debt later on.
Brilliant read.
It gives us the language to efficiently reason about and discuss build concepts with colleagues.
This is a big thing, think about the most recent new starter situation you experienced, about how communication of these common build tasks was expressed. Chances are if it was with a more composable tool, the discussions were fairly detailed, the words 'just like' frequently appeared. If it was with a more rigid tool, the conversation would have been in terms that tool commonly defines.
A great example is the present state of browser development t. Google "backbone sucks site:news.ycombinator.com" and you find tons of comments from people who struggle with backbone - a supercomposable library, not a framework by design.
Composabilty pays off huge in the long, but you need experienced leadership to wield it.
There's also a happy medium in things like Play Framework, a functional scala framework but designed almost as a collection of composable libraries so you can lean on Plays opinions for most things but since it is designed to be composable (compare to "pluggable", or "extensible") so you can swap different pieces out if you like. That is my experience, at least.
tr A-Z a-z | tr -cs a-z '\n' | ...
Since you first turn upper-case characters into lower-case ones, you then get to replace only things that aren't in a-z with newlines, rather than things that aren't in A-Za-z. It saves a whopping three characters!
http://www.mail-archive.com/users@maven.apache.org/msg126205...
At least the people behind Maven took notice that there is a problem and working on something.
The key is, you don't start fighting with Maven.
"The philosophy of Tai Chi Chuan is that if one uses hardness to resist violent force, then both sides are certain to be injured at least to some degree. Such injury, according to tai chi theory, is a natural consequence of meeting brute force with brute force. Instead, students are taught not to directly fight or resist an incoming force, but to meet it in softness and follow its motion while remaining in physical contact until the incoming force of attack exhausts itself or can be safely redirected, meeting yang with yin." (http:// en.wikipedia.org/wiki/Tai_chi_chuan)
If you fight with Maven, you will lose. If you meet it in softness and follow its motion you will attain build enlightenment...
After about a year of experience with Maven, I find that:
* The "surefire" plugin is named ironically. The build often fails without a message about what unit test failed.
* Maven is extremely slow. Eclipse builds the source in 30 seconds max; Maven takes 5 minutes.
* Maven's output is extremely verbose, but if anything goes wrong, it "helpfully" tells you to rerun it with -X -e to get the actual error message and stack trace. You can run it with -X -e all the time if you want, but I think it generates so much output that it actually slows down the build. Yes, really.
* There are a lot of things you just CANNOT DO in Maven. One example is bundling a Maven plugin together with the rest of your Maven source and use that same plugin elsewhere in the project. It fails during the early phases of the default lifecycle because the plugin isn't installed yet. But only by getting to the later phases of the lifecycle can you install the plugin. But you can't do that because the early phases fail. An infinite cycle of despair is right.
* Even the most trivial project takes a few screenfuls of XML to set up in Maven.
* Maven's dependency management is poor, too. If you have some library A that pulls in B, and another library C that pulls in a slightly different version of B, you can get misbuilds. It's your job to identify and fix these problems. They will show up at runtime. And let's not even talk about SNAPSHOT and how horribly that can go wrong.
* Maven is also known for pulling in tons of unnecessary dependencies. But hey, you don't mind 50 more megabytes of jars on your CLASSPATH, do you?
I was honestly expecting the article to address some of these points, instead of vague philosophical ramblings. Seriously, Maven is horrible. This article gives you no inkling of just how bad it is.
That said, I recently had to use ant after many years doing Ruby, and I was surprised to find how many old annoyances were still there, like scarce/painful support for conditional execution. I wanted a task to `cp` in development and `scp/rsync` in production, and I wound up having to duplicate a lot of code. Also I'd have thought that someone would have added the copy task's filter support to scp by now. (If anyone knows a clean way to do any of this, I'd love to hear it.)
To pick an SNMP related example, since I've done a bunch of that, suppose you have a MIB for your organization (using a hacked private OID that you haven't told anybody about for development, because it's easy) and then a lot of other MIBs that depend on that. And then one bright day you get your IETF approved SNMP OID for your organization, and you need to retarget your MIBs to be under that. It could be as simple as changing the base MIB to the new, official, OID and then letting your build tool rebuild the generated files in the correct dependency order--but that's hard to do with Ant. Usually you'll just rebuild all the generated files and then rebuild all the downstream code and then ... It's not trivial in make but it's not especially difficult--make for example has no real knowledge of C code, but with cc -M it doesn't need any.
However we do not yet seem to plug http in the same way we pipe command lines. Something seems to be missing,
Often the real underlying cause is that a business owner with little to no programming knowledge makes something which works ok, but is architectually wrong. For example, bad table structure/relationships. Or after a while, they want to 'put their app online', and asks a poor intern to convert it.
We use Maven with Bamboo for continuous integration and it just works. We play with the idea to move to Gradle b/c it's more powerful, but the effort is non trivial and the real benefits - beside the 'but it's programmable' - not clear.
1) predictability 2) static analysis 3) quality (static typeing vs. duck typing) 4) sophistication/maturity 5) reproducabilty 6) tooling
All that's not always necessary, but if you know the thing you're building has a shelf life of at least 2 years then ruby/rake are pretty shitty tools.
And fuck am I tired of hearing about how saving 10% of your keystrokes during authorship is such a great thing. Most of the time spent on software in in maintenance, so you want better readability than terseness. coffeescript, yaml, etc... are far inferior solutions for most of the uses they get put towards.
[1] http://en.wikipedia.org/wiki/Literate_programming
[2] "Literate Programming" http://comjnl.oxfordjournals.org/content/27/2/97.full.pdf
I am thinking that a build system can be built on top of Java. But Java for shell scripting has some drawbacks that can be alleviated. I am working on these little tool to use regular java for shell scripting, it is auto compilable and it has better abstractions for file manipulation. https://github.com/huherto/jashi
But it has the lisp problem (and now ruby problem) of everyone making their own tooling, without standardisation. (where a "standard" is procrustean: it doesn't exactly fit any situation, but the situation is forced to fit it). Pre-chasm innovators/early-adopters love it; everyone else hates it.
BTW: I don't think "contextual" is a very descriptive term ("composable" is great though)
this: http://www.defmacro.org/ramblings/lisp.html
even though having completely different intentions, shows the parallels quite well, imho
The problem is, when it does not suits you, the competition is not really well known. Gradle maybe ?
mvn archetype:generate ?
I don't recall trying that however, sorry that whole description from the link you provided, it just doesn't make sense to me. In general, when I try to use Maven, Eclipse ends up complaining. Then I fix it so Eclipse is happy then Maven complains.
Maybe the answer for me would really just be get the Maven and the Eclipse people to agree on how to create and manage projects with the Eclipse wizards.
Fine anecdote, but anyone want to take a wager as to the relative time and space complexity of the two solutions? I imagine this is sort of comparing apples and oranges.
So no, taking this anecdote at face value, this guy didn't "one-up" Knuth; they were effectively answering two different questions. There is more to computer science than finding the simplest shell script to solve the 80% case.
Also, you would be surprised just how much "Java" programming you can do with a decent XML editor. IDE's are overrated.
What has Maven ever done for us? http://www.wakaleo.com/blog/what-has-maven-ever-done-for-us
:-)
I can't think of many tools that escape this simple truth.
I'm curious what people are doing with Maven that they manage to get into such a fight with it? Although to be fair, due to issues in its dependency resolution mechanics, it can pull in incorrectly versioned artifacts without ever telling you anything.
It's a relatively thin wrapper around Javac for defining your dependencies and implementing a standard compile, package, test, deploy lifecycle.
In the bad old days you would just half-implement the same thing in an ad-hoc way.
Not a fan.
Various Maven modules were restricted, including Antrun. Because the projects are old and tied to their directory structure of resources, it was more practical to script in Maven rather than follow conventions. Scripting in Maven was quite... challenging.
In this case, the problems arising from Maven also stems from the organization's context.
that's just euphemism for not following maven's conventions, which is where most people's complaint about maven stems from. You either do things the maven way, or the highway. Twisting maven to do what _you_ want, but not how maven likes it is just asking for disaster.
Depending on how bad the mismatch is and how carefully people maintain or break APIs between versions, it can introduce problems.
I've not been into Java enough recently to know if this is fixed or is still affecting Maven3.
And Leiningen uses Maven under the hood :-/