3 ms·

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 htt

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

jamieb 14y ago
One is reproducible. One isn't. YMMV.
- jshen 14y ago
  Well in ruby you could use bundler and it becomes gem 'gem-name' # in Gemfile $ bundle install
  - frugalmail 14y ago
    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 14y ago
      > 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 14y ago
      It does guarantee the version, and I'll ignore the rest of the trolling.
deleted 14y ago
[deleted]
lmm 14y ago
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 14y ago
  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 14y ago

One is reproducible. One isn't. YMMV.

jshen 14y ago
Well in ruby you could use bundler and it becomes gem 'gem-name' # in Gemfile $ bundle install
- frugalmail 14y ago
  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 14y ago
    > 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 14y ago
    It does guarantee the version, and I'll ignore the rest of the trolling.

deleted 14y ago

[deleted]

lmm 14y ago

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 14y ago
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.