[eranation]

You can like maven or hate it, but why can't it be a bit simpler?

e.g. take this selenium install instructions (http://seleniumhq.org/docs/03_webdriver.jsp)

Ruby:

    gem install selenium-webdriver

Java (with Maven):

   <?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>

Then run

   mvn clean install

[lmm]

Sounds like they've cocked up the jars they've produced; you should never have to use exclusions, and it's possible to have a dependency that can be satisfied multiple ways with a default, so you shouldn't need to choose the driver separately if you don't want to. Much of that xml file is what already exists for your project. So the fair comparison is with the section: <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>2.28.0</version> </dependency>

So: 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.

[babebridou]

Exclusions happen, when you need to make do with libraries that have different release schedules or are poorly organized but critical for your current priorities, needs and time constraints. One should see exclusions pretty much as Technical Debt.

Maven becomes brilliant when you start dealing with a large number of modules and profiles, and becomes more tedious when you pass a certain complexity threshold, usually when you have multiple layers of compile-time code generation going on top of each other.

[jamieb]

One is reproducible. One isn't. YMMV.

[jshen]

Well in ruby you could use bundler and it becomes

gem 'gem-name' # in Gemfile

$ bundle install

[frugalmail]

Until you want to do it on a system you just want binaries.

Or until you need to guarentee the version of the library you're bundling

Or you want to run on something other than a MAC-in-crap, like Linux.

RVM has the same problems.

In my opinion, one is for play, and one is for work. If you just want to fuck around and spew code in one long controller that looks like spaghetti, and you don't want to worry about reproducability or quality guarantees or modularity then Ruby build tools are fine to use.

It's incredibly frustrating to hear about people complaining about how tool X doesn't do task Y. They could just STFU and write the plugin.

There is really only one type of plugin that wouldn't work well in Maven, and it's when for some reason you're task doesn't fit into it's "life cycle" pattern. For example, you want something running in the background when you edit SASS, LESS, TypeScript files and you want some processor to just run and deploy in the background continuously. In this scenario, you could keep the Mojo API, but you would have to lose the Maven Framework.

Each tool for it's job.

[lukeholder]

> Or until you need to guarentee the version of the library you're bundling

gem "thing", "3.0.0.beta3"

gem 'rails', :git => 'git://github.com/rails/rails.git', :ref => '4aded'

[jshen]

It does guarantee the version, and I'll ignore the rest of the trolling.