4 ms·

Using maven was a horrible experience for me every single time :( It seemed to download the whole internet and POM files are using everybody's favorite configu

by rb2k_ 14y ago

Using maven was a horrible experience for me every single time :( It seemed to download the whole internet and POM files are using everybody's favorite configuration language: XML

davedx 14y ago
Same. Maven drove me pretty crazy, to be honest. Compare it with Ruby gems or Laravel's bundles, Maven felt like using a ten thousand ton tank to round up sheep.
lmm 14y ago
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.
- rb2k_ 14y ago
  In Ruby: To make sure I have the right version of my libraries I use bundler To make sure I have the right version of my code I use git To make sure I have the right version of other applications I use chef. Has worked fine for me so far... I guess it's the usual unix philosophy where each tool does a single job and does it well.
  - markokocic 14y ago
    So basically one can replace one tool in Java (maven) with four different tools with different conventions and usage scenarios and call the Ruby way simple, and Java way too complicated?
    - batto 14y ago
      It's better to use different good tools, rather than one bad tool. And by the way, since when is Maven SCM? AFAIK Maven just pollutes SCM with it's dumb release plugin.
      - st3fan 14y ago
        If you don't want your artifacts uploaded to some place (like your SCM) then don't do it. But let me explain how useful this actually is. When working on a Java project with a team of people, we usually use Maven and some CI tool like Jenkins or Bamboo. People commit code, Jenkins run a Maven build and then either Jenkins or Maven uploads build artifacts to a central repository. Artifacts usually are: the jar/war/ear file, the -src.jar and the -javadoc.jar. If code is finished then it will be a x.y release, otherwise it will be uploaded as something like 1.0-SNAPSHOT. Snapshots are usually timestamped. Now I have a standard place where other projects can find dependencies, where the ops team can grab releases, where developers can find dependencies, code and documentation. Three extra lines in a pom.xml and you get all that. Your IDE now picks it up and keeps it up to date. You can click/hotkey on anything and it will show source or documentation. You call it pollution, I call it a great and pretty much completely automatic infrastructure that makes development so much easier.
      - edwinnathaniel 14y ago
        Err, I'd have to disagree with the assessment that Ruby tools are good and Maven is bad.
    - ZitchDog 14y ago
      (maven only solves one of those problems)
  - edwinnathaniel 14y ago
    Some libraries that are being stored at Maven Repository have 2 additional artifacts: source-jar and javadoc-jar. If you're using Eclipse and Maven plugin, the beauty is that when you hit a shortcut key to navigate to either the Definition or the Implementation of 3rd-party open source library, the Maven plugin will download the source code for you and voila, no configuration or anything like that needs to be done with Eclipse (telling Eclipse where the path, etc). It's powerful.
- batto 14y ago
  What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's why all Maven builds that are not simple jar of classes tends to have long sequentional calls of build plugins. I see it this way: First we had bash and make and ability to do almost everything (run other programs, ...) by using the right thing/language for the job. There was only lack of the functions to deal with Java builds and package management. Then we had Ant, XML programming language with very limited possibilites (I don't regard targets as a feature). But at least we could express what we wanted. Then we had Maven. If we needed something special we need to add it to sequence of build plugins (in several hardcoded build phases). Mostly we resort to do things in Ant plugin. This is why I hate Java. Because of such idiocy.
  - lmm 14y ago
    The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.
    - batto 14y ago
      "ability to call external program" is a bug? Well, I do it on almost every line in my super-readable bash scripts. You say it's a bug because you mindlessly follow this Maven doctrine. My projects are unique and so is the way how I build them. Separating classpath source into 'java/' and 'resources/'? It's just masturbation. Why do I need to put my sources in 'src/main/java' and 'src/main/resources' if I know that I'll be using only Java in every project? Writing plugins... why whould I want to do such unpleasant thing as writing Maven plugin when I can usually do it in several lines in script?
    - 14y ago
- ollysb 14y ago
  For a number of reasons Bundler/rubgems does a far better job of reproducible builds. 1) Maven doesn't generate an equivalent of Bundler's lock file. It resolves the versions to be used on each build. If you have dependencies on snapshot versions then there's no way to ensure that all developers are using the same snapshot. OK, you can always specify versions explicitly, but then you lose the benefits of snapshots etc. Bundler's lock file allows you to easily check for newer versions(a gem at a time if you like) without losing reproducible builds. 2) Developers can't upload their jars to the central maven repository. There are gatekeepers. This means that the latest versions of many projects aren't in the central repository. For those projects you have to use their own specific repository. This leads to problem 3. With rubygems developers can upload gems straight into rubygems.org. Also, because most projects are in github and you can specify git dependencies with Bundler you're able to depend on any version of a project(regardless of whether or not it's been released to rubygems.org), all the way down to the commit level. 3) 3rd party repositories change and can be unreliable. This means a jar can become unavailable without any notice. In practice the only way to guard against this is to use a proxy repository like nexus or artifactory, yay, another server to maintain...
  - lmm 14y ago
    1) The whole value of depending on snapshots is letting each developer run everything against their local, possibly-modified versions; there would be no point forcing snapshot builds to be reproducible. Release builds aren't allowed to depend on snapshots. Maybe I'm just too used to maven, but I don't see how you'd do it any other way. 2) Gatekeepers have their advantages; how you run a repository is pretty independent of the build tool. It would be possible to start a "anyone can upload anything" maven repository if this was thought useful. 3) Surely the notion of having your build depend on a random third-party git repository is far more worrying than depending on a random third-party maven repository - wouldn't you need to set up a git mirror server, which is more effort than nexus or artifactory?
    - ollysb 14y ago
      First of all, let me say I'm not a maven hater. If I was working on a java project I'd use it. 1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me). 2) It's true it would be possible to start a "anyone can upload anything" repository. Having seen how well rubygems.org works in this scenario I think the java community should really get one organised. Either by enhancing the central maven repository or replacing it entirely(it's always been damn slow to browse anyway). 3) In my experience Github projects tend to be pretty persistent, if you have any concerns though you can always hit the fork button and depend on that. Having said that, using git dependencies is definitely the plan B option.
st3fan 14y ago
"It seemed to download the whole internet" It just grabs your project's dependencies and probably some extra stuff the first time you use maven. This is not really different from python or ruby build systems.
cafebabe 14y ago
Lets face it: There is no system that fits all the needs of everyone and is simpel and easy to use from everyones personal point of view. There is no such thing and each system that does say otherwise, lies. All specializations come with tradeoffs.

by rb2k_ 14y ago

Using maven was a horrible experience for me every single time :( It seemed to download the whole internet and POM files are using everybody's favorite configuration language: XML

davedx 14y ago

Same. Maven drove me pretty crazy, to be honest. Compare it with Ruby gems or Laravel's bundles, Maven felt like using a ten thousand ton tank to round up sheep.

lmm 14y ago

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.

rb2k_ 14y ago
In Ruby: To make sure I have the right version of my libraries I use bundler To make sure I have the right version of my code I use git To make sure I have the right version of other applications I use chef. Has worked fine for me so far... I guess it's the usual unix philosophy where each tool does a single job and does it well.
- markokocic 14y ago
  So basically one can replace one tool in Java (maven) with four different tools with different conventions and usage scenarios and call the Ruby way simple, and Java way too complicated?
  - batto 14y ago
    It's better to use different good tools, rather than one bad tool. And by the way, since when is Maven SCM? AFAIK Maven just pollutes SCM with it's dumb release plugin.
    - st3fan 14y ago
      If you don't want your artifacts uploaded to some place (like your SCM) then don't do it. But let me explain how useful this actually is. When working on a Java project with a team of people, we usually use Maven and some CI tool like Jenkins or Bamboo. People commit code, Jenkins run a Maven build and then either Jenkins or Maven uploads build artifacts to a central repository. Artifacts usually are: the jar/war/ear file, the -src.jar and the -javadoc.jar. If code is finished then it will be a x.y release, otherwise it will be uploaded as something like 1.0-SNAPSHOT. Snapshots are usually timestamped. Now I have a standard place where other projects can find dependencies, where the ops team can grab releases, where developers can find dependencies, code and documentation. Three extra lines in a pom.xml and you get all that. Your IDE now picks it up and keeps it up to date. You can click/hotkey on anything and it will show source or documentation. You call it pollution, I call it a great and pretty much completely automatic infrastructure that makes development so much easier.
    - edwinnathaniel 14y ago
      Err, I'd have to disagree with the assessment that Ruby tools are good and Maven is bad.
  - ZitchDog 14y ago
    (maven only solves one of those problems)
- edwinnathaniel 14y ago
  Some libraries that are being stored at Maven Repository have 2 additional artifacts: source-jar and javadoc-jar. If you're using Eclipse and Maven plugin, the beauty is that when you hit a shortcut key to navigate to either the Definition or the Implementation of 3rd-party open source library, the Maven plugin will download the source code for you and voila, no configuration or anything like that needs to be done with Eclipse (telling Eclipse where the path, etc). It's powerful.
batto 14y ago
What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's why all Maven builds that are not simple jar of classes tends to have long sequentional calls of build plugins. I see it this way: First we had bash and make and ability to do almost everything (run other programs, ...) by using the right thing/language for the job. There was only lack of the functions to deal with Java builds and package management. Then we had Ant, XML programming language with very limited possibilites (I don't regard targets as a feature). But at least we could express what we wanted. Then we had Maven. If we needed something special we need to add it to sequence of build plugins (in several hardcoded build phases). Mostly we resort to do things in Ant plugin. This is why I hate Java. Because of such idiocy.
- lmm 14y ago
  The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand. If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.
  - batto 14y ago
    "ability to call external program" is a bug? Well, I do it on almost every line in my super-readable bash scripts. You say it's a bug because you mindlessly follow this Maven doctrine. My projects are unique and so is the way how I build them. Separating classpath source into 'java/' and 'resources/'? It's just masturbation. Why do I need to put my sources in 'src/main/java' and 'src/main/resources' if I know that I'll be using only Java in every project? Writing plugins... why whould I want to do such unpleasant thing as writing Maven plugin when I can usually do it in several lines in script?
  - 14y ago
ollysb 14y ago
For a number of reasons Bundler/rubgems does a far better job of reproducible builds. 1) Maven doesn't generate an equivalent of Bundler's lock file. It resolves the versions to be used on each build. If you have dependencies on snapshot versions then there's no way to ensure that all developers are using the same snapshot. OK, you can always specify versions explicitly, but then you lose the benefits of snapshots etc. Bundler's lock file allows you to easily check for newer versions(a gem at a time if you like) without losing reproducible builds. 2) Developers can't upload their jars to the central maven repository. There are gatekeepers. This means that the latest versions of many projects aren't in the central repository. For those projects you have to use their own specific repository. This leads to problem 3. With rubygems developers can upload gems straight into rubygems.org. Also, because most projects are in github and you can specify git dependencies with Bundler you're able to depend on any version of a project(regardless of whether or not it's been released to rubygems.org), all the way down to the commit level. 3) 3rd party repositories change and can be unreliable. This means a jar can become unavailable without any notice. In practice the only way to guard against this is to use a proxy repository like nexus or artifactory, yay, another server to maintain...
- lmm 14y ago
  1) The whole value of depending on snapshots is letting each developer run everything against their local, possibly-modified versions; there would be no point forcing snapshot builds to be reproducible. Release builds aren't allowed to depend on snapshots. Maybe I'm just too used to maven, but I don't see how you'd do it any other way. 2) Gatekeepers have their advantages; how you run a repository is pretty independent of the build tool. It would be possible to start a "anyone can upload anything" maven repository if this was thought useful. 3) Surely the notion of having your build depend on a random third-party git repository is far more worrying than depending on a random third-party maven repository - wouldn't you need to set up a git mirror server, which is more effort than nexus or artifactory?
  - ollysb 14y ago
    First of all, let me say I'm not a maven hater. If I was working on a java project I'd use it. 1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me). 2) It's true it would be possible to start a "anyone can upload anything" repository. Having seen how well rubygems.org works in this scenario I think the java community should really get one organised. Either by enhancing the central maven repository or replacing it entirely(it's always been damn slow to browse anyway). 3) In my experience Github projects tend to be pretty persistent, if you have any concerns though you can always hit the fork button and depend on that. Having said that, using git dependencies is definitely the plan B option.

st3fan 14y ago

"It seemed to download the whole internet" It just grabs your project's dependencies and probably some extra stuff the first time you use maven. This is not really different from python or ruby build systems.

cafebabe 14y ago

Lets face it: There is no system that fits all the needs of everyone and is simpel and easy to use from everyones personal point of view. There is no such thing and each system that does say otherwise, lies. All specializations come with tradeoffs.