Well... If by XML-based things you are thinking of Maven, they're not really at the same level. Maven is much more higher-level, and is fully declarative, which is both a blessing and a curse. I would not describe it as a general-purpose build system, it's really made for the Java ecosystem, but in this context, it works well for a majority of projects, because they can follow the rails. And it does handle out of the box automated retrieval of dependencies, which is way outside the scope of make.
It has its hear in the right place, though. High-level build systems should strive to be as declarative as possible. It's the rest of the design which is problematic :)
Just to be clear, I'm not against XML at all. Maven does more but can be a pain to program compared to older systems like ant, which is also XML-based. Configuring plugins to fire at the right point in the build cycle (e.g., package vs. install) comes lightly to mind.
It's gotten a lot better because there are many examples now accessible with Google. Overall I'm pretty happy with maven now. It works.
It is, but it uses XML right: for a declarative document, and one that has tools for editing rather than having to do it by hand. Maven is glorious because it ensures your builds are actually reproducible, something which I've never seen any other language or build tool accomplish.
I think the declarative model is why I prefer Maven over any other build system I've worked with, yeah XML is a little noisy but if it's really that big of a deal there's the polyglot plugin. Maven POM's are pretty easy to figure out once you've worked with them for a while, there's a learning curve when you start adding plugins and have to get at least a basic understanding of build phases - but a large chunk of projects need nothing more than the default plugin bindings, they just add their dependencies and go off to the races.
Grouping ANT/Maven together because of XML is a very superficial association to make. ANT despite what it claims is essentially an inflexible programming language, which offers very few benefits over java (and many disadvantages), except that it is interpreted (not compiled), has a library of build tasks and can be stuck in the root of a project without looking like source code. XML is a big issue in ant because it is a very poor choice for writing a programming language.
Maven is a build framework, into which you make your program fit, by decomposing it into maven projects ... etc. etc. XML is a perfectly good choice for configuration here. The core problem with Maven is poor design. For one, it has tried to make things simpler than they are, and does not recognise that some programming projects are fundamentally not amenable to a module structure (i.e. what ebuild calls products). It also makes developing across the dependency boundary (i.e. your program + the library) very cumbersome indeed.
Actually, Maven uses XML right - as configuration, not code. This is where Ant was terrible - you ended up writing imperative code with XML statements.
XML syntax is very simple, has very good IDE support (navigation, autocompletion - thanks to xml schema, etc.. can any IDE autocomplete dependencies from repository in .sbt files?). Maven itself provides good easy ways to reuse the configuration across multiple modules.
If you exclude dependencies than for more complex projects the no of lines in pom.xml build files is somewhere between 50 - 100 % more, so it is not like .sbt (or gradle - which I find superior to both) is 10 times less verbose.
XML is one thing, MSBuild is another one. It's the only widely used tool where you can't really hand-craft (and therefore fully understand) a complete build file.
Compare Maven's pom.xml with a MSBuild file. Both XML, both verbose, but other than that, radically different.
and i dont particularly think that using xml is that bad. The schema is well defined, and gives you good autocompletion in any competent IDE (such as intellij).
It took some iterations before maven 3 became "good", so people forget that it wasn't as nice before now! Unfortunately, it seems that the lessons learned there is never really disseminated to other ecosystems - perhaps due to prejudice against "enterprisey" java. Yet, these package managers are now facing the sorts of problems solved in java.
When you lead with "XML is bad", I feel you're missing the wood for the trees.
What I really like about Maven is that the build file is declarative.
Now, would it be better in JSON or YAML? That's really a matter of taste.
Also, Maven artifact repositories have one massive feature that everyone else omits for reasons I can't fathom - verified package namespaces, so no typosquatting here.
Many people dont appreciate Maven because they get hung up on XML. If you need to do anything in Maven which isnt dead easy to do in XML you just write a plugin in Java which is the language you are coding in anyway.
Maven is declaritive. IMO it's the best of the Java build tools. Gradle is not declaritive, unless it's changed since the last time I looked at it.
Maven has problems. It's not perfect by any means. I would love to see it rewritten, get rid of the verbose XML which makes viewing dependencies hard and fix the craziness around generated code.
Honestly, I'm tempted to make a fork of Cargo for Java, it's nearly perfect. But this goes against my opinion that build tools should be in the same language as the code they build.
I happen to think that maven is a good idea in principle, but poorly designed. One fundamental issue is that it does not distinguish between what I call 'products' and 'modules'. Modules have transitive dependencies and tend to have a common structure, and products do not.
When you are building a product (e.g. an installer, some documentation, a website ... etc.) with the build tool, what you create is an artifact, that once built you can treat independently of its dependencies. A module is library code, and when you depend on it you implicitly depend on its dependencies as well.
Build languages/dsls are a complete intellectual cul-de-sac. Java is a perfectly acceptable (in fact quite decent) language for doing build tasks. There is nothing in ant that cannot be equally concisely written in java, given the right library support.
I have written more this subject in the articles on the website.
> What is XML good at? (by good I mean better than alternatives like JSON, YAML, HAML, etc)
It has a single standard way of doing schemata that all the tools support, which is great. The maven pom.xml format is a much clearer way to specify a dependency than most of the alternatives (which often use an excessively clever concise form), and has really good autocomplete when editing it in eclipse (because eclipse understands the schema and so can offer autocomplete based on the elements that make sense at that point in the document).
If XML had just not bothered with namespaces I think it would have worked really well.
I've never had any issue nor felt that Maven is overly complicated so far having done a few large projects with minimum Maven overhead (i.e.: haven't had the need to customize it).
I do agree with you that XML makes programmability aspect of it a little bit more complex than it should be (you still can write plugins if you have to, as opposed to use XML).
It has its hear in the right place, though. High-level build systems should strive to be as declarative as possible. It's the rest of the design which is problematic :)
reply