11 ms·

Maven is broken by design

143 points by richardw 13y ago

frankzinger 13y ago
Incremental builds: I am working at a Java shop at the moment and was amazed to find that even the resident Maven experts clean before every build. To me incremental builds are one of the most important functions of a build system, but it seems that users of Maven and other well-known build systems used in the Java world have given up on it because it just doesn't work. So anything which fixes even only this problem would be a step in the right direction.
- jpollock 13y ago
  I read how TeamCity did their incremental builds and wrote my own script. I drop an anchor, detect changed files and then build up a list of modules that need to be rebuilt. I then tell maven to build those modules and their downstream dependencies. Speeds things up a tonne. http://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/ http://blog.jetbrains.com/teamcity/2012/03/incremental-build...
koevet 13y ago
I don't understand why this is still a matter of discussion after so many years of blood and tears. Maven is dead, everyone else is moving to Gradle (Spring, Android, Hibernate, etc.). I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS. If you work in Java and you are still stuck with Maven, please, take a look at Gradle.
- auvrw 13y ago
  > If you work in Java and you are still stuck with Maven, please, take a look at Gradle. or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks). after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically, "do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.
  - ajanuary 13y ago
    Ironically the biggest pain with Ivy is that 99% of your dependencies will be pulled in from Maven oriented sources, so you still have to deal with Maven's deficiencies around dependency configurations.
    - smrtinsert 13y ago
      how so? you can even use regexs easily to specify which transitive deps you don't want. what are you missing?
  - koevet 13y ago
    Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine. Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle. Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
    - gaius 13y ago
      I looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
      - koevet 13y ago
        Well, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be. A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
      - IanCal 13y ago
        > Then carried on using Makefiles How do you deal with versioned dependencies with Makefiles?
- Randgalt 13y ago
  No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven. I hated Maven until I tried the alternatives.
  - koevet 13y ago
    > incomprehensible build files ala Ant Please, explain incomprehensible (or show an example)
    - davidgerard 13y ago
      Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity! To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.
    - Randgalt 13y ago
      Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.
      - koevet 13y ago
        Thanks for the link. To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.
        13y ago
dschiptsov 13y ago
Just maven or the whole Java philosophy of avoiding any understanding/researching/thinking before beginning to pile it up inside an IDE?)
- cuillevel3 13y ago
  I don't think there is an actual maven IDE. You normally use it from the command line, since it's integration into IDEs is serverly (eclipse...) lacking.
  - chii 13y ago
    If you use Intellij IDEA, their maven integration is top notch. light years ahead of eclipse.
    - chinpokomon 13y ago
      I concur. I'm the only developer in my shop using IntelliJ. Everyone else uses NetBeans. Whenever someone asks me how to setup NetBeans to handle builds as easily as I do, I have to shrug. Simple things, like switching to offline mode or turning off tests is a chore for NetBeans, but it is just a simple button click for me. If I want to target a specific build profile, I check a check box. As I'm the one who maintains the build, configuring pom.xml files and setting up modules, I can see how it can become difficult for someone who doesn't have the experience I do. OTOH, I've yet to find a problem that stumps me when I'm doing things the Maven way, and I rather enjoy the flexibility and power it provides me. Once I've got the basics in place, maintaining the system is almost trivial.
  - smrtinsert 13y ago
    I don't use maven for my builds these days but that's completely wrong. configuring deps is painless as is adding plugins. I've used it to build maven projs as well as osgi projs.
  - liveoneggs 13y ago
    netbeans can use maven out of the box
chopin 13y ago
I am not very experienced in using Maven, but the biggest problem I have with it is, that it is hard to tell (at least for my level of experience) from where dependencies are pulled. Is it my local mirror, is it something on a central nexus in the company or is it totally from outside? Build reproducibility, which the author mentions is another issue. When I scrub the local mirror, the outcome can be completely different. Previously builds where working fine, when I scrub, everything breaks. This is mainly due to non-local dependencies which had been cached locally, but not replaced by most recent versions. Another suspicion I have is that most build scripts are slapped together by googling until it works. Which of course is prone to being fragile (not to mention legal issues because it is opaque from where all stuff is pulled).
- fs111 13y ago
  Never, ever, ever add any repositories to your pom.xml. Never. Have one central repo (nexus, artifactory, whatever) for your organization and make it a mirror of all others via settings.xml, not in the pom. This adds a lot to build stability and reproducibility.
richardw 13y ago
He and others continue discussion here, with some depth. https://plus.google.com/113945685385052458154/posts/7LHoGXQdkri https://plus.google.com/113945685385052458154/posts/7LHoGXQd...
drivebyacct2 13y ago
Hm, maybe if someone made a plugin that would show that even manen were mis-resolving dependencies even when building itself. Like 3 years ago. Hm.
hansgru 13y ago
> Maven is broken by design It might be, but it still has it's merits. It was one of the first, and many other improved tools can't work without it's repositories. I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency diagram that I find useful, even if I don't use Maven for something else in a project. Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.
- mercurial 13y ago
  > Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed. I don't understand the local vs global dependency thing. What does NPM do differently from Maven?
  - delluminatus 13y ago
    NPM stores dependencies in a node_modules folder within the project directory, i.e. "locally." It does have a command-line flag to store something globally, though -- useful for dependencies with executables. I'm not a Java developer but it sounds like Maven stores all its dependencies globally (like in /usr/share/java). I'm not sure why that would be a "pain point" except making it hard to do different versions of the same library.
    - brown9-2 13y ago
      The local repository cache is in ~/.m2/repository and each artifact is versioned, so you would have ~/.m2/repository/com/foo/bar/1.0/bar.jar ~/.m2/repository/com/foo/bar/1.1/bar.jar etc., which prevents you from pulling in version 1.0 when you intend 1.1.
    - mercurial 13y ago
      Maven stores dependencies in ~/.m2/repository (so "globally" per user). However, it can and does store parallel versions of the same library without issue. It's not much of an issue unless you need to copy your source folder elsewhere, in which case you either need to copy your .m2 (with stuff from all your various projects) or wait until maven re-downloads everything.
hansjorg 13y ago
> a pom.xml can only list a single source folder. If you have more than one (for whichever reason) I agree that this example demonstrates that the Maven model is broken, but why would you structure your project like this rather than using another module or a submodule? Maybe it's just lack of experience, but I highly prefer the rigidity of Maven projects compared to some of the messes that more expressive build systems allow.
hrjet 13y ago
One thing which I detest about maven, it uses http by default. Getting it to use https requires a lot of work[1] so many don't use it. By default, not only are you downloading a truck load of jars from the internet and running them locally, you are fetching them over an insecure channel! [1]: http://maven.apache.org/guides/mini/guide-repository-ssl.html http://maven.apache.org/guides/mini/guide-repository-ssl.htm...
- nl 13y ago
  Honestly, so what? What is HTTPS supposed to protect against in this case? 1) If you are using it to protect against snooping (why?!) then you must realise that the logs of many Maven repositories are effectively public (eg, I believe Apache committers can access the repo.maven logs pretty easily). For protection against snooping, use a local repo. 2) If you are expecting it to protect you against tampering in transport, then you are better off using a local repo (again). It's much more likely artifacts are tampered with at the remote repository rather than during the transport phase.
  - michaelt 13y ago
    It's for when you trust the public repo operator, you trust the authors of the package you're downloading, you trust your local machine, you trust the repo operator's SSL CA, but you don't trust the connection from your computer to the public repo. For example, if you're using dodgy public wifi.
  - andor 13y ago
    It's much more likely artifacts are tampered with at the remote repository rather than during the transport phase. MITMing the public wifi at some coffee store is much easier than breaking into the official Maven repositories. At least I hope so. That's why RPM and DPKG packages are signed.
    - danieldk 13y ago
      Artifacts in the central repository are also signed, it's a requirement: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement https://docs.sonatype.org/display/Repository/Sonatype+OSS+Ma... Checking the actual signatures is another story ;).
tomohawk 13y ago
Switched to buildr (http://buildr.apache.org/ http://buildr.apache.org/) years ago. So much better than maven.
- stephen 13y ago
  +1 for buildr. It admittedly takes awhile to learn the DSL, but it seems like all of these DSL build tools take awhile to learn. (I think that was one really nice thing about Ant--you could scan their manual/list of tasks and understand it very quickly.) It seems a little odd using Ruby to build Java projects, but ironically I actually prefer that over Groovy. This is horrible for me to say, but I'd like Groovy to gracefully go away--it lost the Java.next race (they were stubborn about dynamic typing for way too long) and I feel the only reason it's still around are for the admittedly nice frameworks it sprouted: Grails and Gradle. The language itself is "meh", IMO. ...although it bothers me to no end that a dynamic language like Groovy had compile-time AST translation way before other (similarly mainstream) static languages like Scala. Anyway. Gradle's momentum is impressive. Perhaps I can unlearn my Groovy bias.
Communitivity 13y ago
I'm a sw engineer programming Java since 1996. I started using Maven when it first came out as the declarative build language hooked me, and became the local Maven expert. I've watched it grow with pride, and sometimes in anger. I still believe a declarative build language is best, but it won't be in XML. I suspect it will eventually be in something like OWL, whatever comes along after OWL that fixes its issues. So as of a few years ago I too moved on to Gradle and have loved it. But... Language based build systems offer more expressiveness, but that is also more rope to hang yourself with if you get someone that doesn't know Gradle well doing tinkering with your build. For example we had someone add a custom checkstyle report to an Android project using Gradle. After their edits it stopped working because of the way the Android plugin was designed, bringing the build down for several hours. I came in, rewrote the Gradle build file to workaround the issue and it worked. Then I documented to the person why it hadn't worked and what I did to fix it. As with the adoption of anything that gives you more rope to hang yourself with, it's a necessary piece of Gradle adoption to document your practices and train your team well.
- twic 13y ago
  "I documented to the person" - that is a euphemism i will have to remember. Yeah, I documented it to Jim. That's a documenting he won't forget in a hurry, make no mistake.
ssfsx17 13y ago
What is inherently virtuous about a build tool being pure-declarative and having no imperative impurities?
- andrewaylett 13y ago
  Any tool can get hold of the full state of how to build the project, then interpret it itself, rather than having to work out what the imperative code is trying to achieve.
ExpiredLink 13y ago
Do it the Maven way and you'll have no problems. Fight the Maven way and you'll end up in a mess. tl;dr Understand the tools you use.
- ghostdiver 13y ago
  Maven killed some great open source projects, i.e. Apache Cocoon
  - ExpiredLink 13y ago
    According to the hp Apache Cocoon is based on XML/XSLT and Spring. If it failed I bet not because of Maven ...
    - ghostdiver 13y ago
      except that in Cocoon you are not forced to use XML/XSLT. Try to make sample webapp using Maven 2: http://cocoon.apache.org/2.2/1159_1_1.html http://cocoon.apache.org/2.2/1159_1_1.html I bet you will fail thanks to some random maven quirk:) Spring is just some Java library, XML/XSLT is too simple to break anything.
- jebblue 13y ago
  I've tried on many occasions to make Maven work with Eclipse but Maven nearly always finds a way to mess up Eclipse's excellent project management abilities. I'd say that if you just write code in an editor then Maven makes a lot of sense, if you use a powerful IDE like Eclipse then Maven becomes an unwieldy and unnecessary challenge.
- ebiester 13y ago
  That's fine, so long as the problem you're trying to solve is easily expressed within Maven's structure. And sometimes, expressing it withing Maven's structure can lead to very slow builds, at least within my experience. But perhaps I'm prejudiced; I hate maven, and have since my first experience with the Mvn 2 betas. You know when you see a new technology and you say, "this is painful now, but it's going to be worth it in the end?" I got the "this is painful now, and is only going to get worse as plugins depend on crazy ass behavior" feeling. From everything I've seen since, I was right.
timr 13y ago
Reading Java people's complaints about the deficiencies in their fifty different build tools makes me want to force them all to use Make.
- angersock 13y ago
  They typically spell it "ant".
  - ExpiredLink 13y ago
    That's the main problem people have with Maven. They try to use it like make/Ant - and fail miserably.
    - VladRussian2 13y ago
      "fail miserably" would be fine. Unfortunately it is "live miserably".
  - timr 13y ago
    Yeah, they misspelled it.
Randgalt 13y ago
FYI - http://tesla.io/tesla/index.html http://tesla.io/tesla/index.html

143 points by richardw 13y ago

Incremental builds: I am working at a Java shop at the moment and was amazed to find that even the resident Maven experts clean before every build. To me incremental builds are one of the most important functions of a build system, but it seems that users of Maven and other well-known build systems used in the Java world have given up on it because it just doesn't work. So anything which fixes even only this problem would be a step in the right direction.

jpollock 13y ago
I read how TeamCity did their incremental builds and wrote my own script. I drop an anchor, detect changed files and then build up a list of modules that need to be rebuilt. I then tell maven to build those modules and their downstream dependencies. Speeds things up a tonne. http://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/ http://blog.jetbrains.com/teamcity/2012/03/incremental-build...

koevet 13y ago

I don't understand why this is still a matter of discussion after so many years of blood and tears. Maven is dead, everyone else is moving to Gradle (Spring, Android, Hibernate, etc.). I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS. If you work in Java and you are still stuck with Maven, please, take a look at Gradle.

auvrw 13y ago
> If you work in Java and you are still stuck with Maven, please, take a look at Gradle. or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks). after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically, "do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.
- ajanuary 13y ago
  Ironically the biggest pain with Ivy is that 99% of your dependencies will be pulled in from Maven oriented sources, so you still have to deal with Maven's deficiencies around dependency configurations.
  - smrtinsert 13y ago
    how so? you can even use regexs easily to specify which transitive deps you don't want. what are you missing?
- koevet 13y ago
  Ivy is "only" a dependency manager, you can't build stuff with it. Gradle was originally based on Ivy but they decided to roll their own Ivy/Maven compatible dependency engine. Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle. Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
  - gaius 13y ago
    I looked at all these tools... Then carried on using Makefiles. Seriously, people, building has been a solved problem for decades. Let's all stop fooling around and concentrate on actually writing code!
    - koevet 13y ago
      Well, I use VIM to write Java/Scala/Groovy/Python code but unfortunately large, complex projects do exists and the java ecosystem is particularly good at making things more complex that they need to be. A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
    - IanCal 13y ago
      > Then carried on using Makefiles How do you deal with versioned dependencies with Makefiles?
Randgalt 13y ago
No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven. I hated Maven until I tried the alternatives.
- koevet 13y ago
  > incomprehensible build files ala Ant Please, explain incomprehensible (or show an example)
  - davidgerard 13y ago
    Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity! To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.
  - Randgalt 13y ago
    Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.
    - koevet 13y ago
      Thanks for the link. To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.
      - 13y ago

dschiptsov 13y ago

Just maven or the whole Java philosophy of avoiding any understanding/researching/thinking before beginning to pile it up inside an IDE?)

cuillevel3 13y ago
I don't think there is an actual maven IDE. You normally use it from the command line, since it's integration into IDEs is serverly (eclipse...) lacking.
- chii 13y ago
  If you use Intellij IDEA, their maven integration is top notch. light years ahead of eclipse.
  - chinpokomon 13y ago
    I concur. I'm the only developer in my shop using IntelliJ. Everyone else uses NetBeans. Whenever someone asks me how to setup NetBeans to handle builds as easily as I do, I have to shrug. Simple things, like switching to offline mode or turning off tests is a chore for NetBeans, but it is just a simple button click for me. If I want to target a specific build profile, I check a check box. As I'm the one who maintains the build, configuring pom.xml files and setting up modules, I can see how it can become difficult for someone who doesn't have the experience I do. OTOH, I've yet to find a problem that stumps me when I'm doing things the Maven way, and I rather enjoy the flexibility and power it provides me. Once I've got the basics in place, maintaining the system is almost trivial.
- smrtinsert 13y ago
  I don't use maven for my builds these days but that's completely wrong. configuring deps is painless as is adding plugins. I've used it to build maven projs as well as osgi projs.
- liveoneggs 13y ago
  netbeans can use maven out of the box

chopin 13y ago

I am not very experienced in using Maven, but the biggest problem I have with it is, that it is hard to tell (at least for my level of experience) from where dependencies are pulled. Is it my local mirror, is it something on a central nexus in the company or is it totally from outside? Build reproducibility, which the author mentions is another issue. When I scrub the local mirror, the outcome can be completely different. Previously builds where working fine, when I scrub, everything breaks. This is mainly due to non-local dependencies which had been cached locally, but not replaced by most recent versions. Another suspicion I have is that most build scripts are slapped together by googling until it works. Which of course is prone to being fragile (not to mention legal issues because it is opaque from where all stuff is pulled).

fs111 13y ago
Never, ever, ever add any repositories to your pom.xml. Never. Have one central repo (nexus, artifactory, whatever) for your organization and make it a mirror of all others via settings.xml, not in the pom. This adds a lot to build stability and reproducibility.

richardw 13y ago

He and others continue discussion here, with some depth. https://plus.google.com/113945685385052458154/posts/7LHoGXQdkri https://plus.google.com/113945685385052458154/posts/7LHoGXQd...

drivebyacct2 13y ago

Hm, maybe if someone made a plugin that would show that even manen were mis-resolving dependencies even when building itself. Like 3 years ago. Hm.

hansgru 13y ago

> Maven is broken by design It might be, but it still has it's merits. It was one of the first, and many other improved tools can't work without it's repositories. I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency diagram that I find useful, even if I don't use Maven for something else in a project. Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.

mercurial 13y ago
> Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed. I don't understand the local vs global dependency thing. What does NPM do differently from Maven?
- delluminatus 13y ago
  NPM stores dependencies in a node_modules folder within the project directory, i.e. "locally." It does have a command-line flag to store something globally, though -- useful for dependencies with executables. I'm not a Java developer but it sounds like Maven stores all its dependencies globally (like in /usr/share/java). I'm not sure why that would be a "pain point" except making it hard to do different versions of the same library.
  - brown9-2 13y ago
    The local repository cache is in ~/.m2/repository and each artifact is versioned, so you would have ~/.m2/repository/com/foo/bar/1.0/bar.jar ~/.m2/repository/com/foo/bar/1.1/bar.jar etc., which prevents you from pulling in version 1.0 when you intend 1.1.
  - mercurial 13y ago
    Maven stores dependencies in ~/.m2/repository (so "globally" per user). However, it can and does store parallel versions of the same library without issue. It's not much of an issue unless you need to copy your source folder elsewhere, in which case you either need to copy your .m2 (with stuff from all your various projects) or wait until maven re-downloads everything.

hansjorg 13y ago

> a pom.xml can only list a single source folder. If you have more than one (for whichever reason) I agree that this example demonstrates that the Maven model is broken, but why would you structure your project like this rather than using another module or a submodule? Maybe it's just lack of experience, but I highly prefer the rigidity of Maven projects compared to some of the messes that more expressive build systems allow.

hrjet 13y ago

One thing which I detest about maven, it uses http by default. Getting it to use https requires a lot of work[1] so many don't use it. By default, not only are you downloading a truck load of jars from the internet and running them locally, you are fetching them over an insecure channel! [1]: http://maven.apache.org/guides/mini/guide-repository-ssl.html http://maven.apache.org/guides/mini/guide-repository-ssl.htm...

nl 13y ago
Honestly, so what? What is HTTPS supposed to protect against in this case? 1) If you are using it to protect against snooping (why?!) then you must realise that the logs of many Maven repositories are effectively public (eg, I believe Apache committers can access the repo.maven logs pretty easily). For protection against snooping, use a local repo. 2) If you are expecting it to protect you against tampering in transport, then you are better off using a local repo (again). It's much more likely artifacts are tampered with at the remote repository rather than during the transport phase.
- michaelt 13y ago
  It's for when you trust the public repo operator, you trust the authors of the package you're downloading, you trust your local machine, you trust the repo operator's SSL CA, but you don't trust the connection from your computer to the public repo. For example, if you're using dodgy public wifi.
- andor 13y ago
  It's much more likely artifacts are tampered with at the remote repository rather than during the transport phase. MITMing the public wifi at some coffee store is much easier than breaking into the official Maven repositories. At least I hope so. That's why RPM and DPKG packages are signed.
  - danieldk 13y ago
    Artifacts in the central repository are also signed, it's a requirement: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement https://docs.sonatype.org/display/Repository/Sonatype+OSS+Ma... Checking the actual signatures is another story ;).

tomohawk 13y ago

Switched to buildr (http://buildr.apache.org/ http://buildr.apache.org/) years ago. So much better than maven.

stephen 13y ago
+1 for buildr. It admittedly takes awhile to learn the DSL, but it seems like all of these DSL build tools take awhile to learn. (I think that was one really nice thing about Ant--you could scan their manual/list of tasks and understand it very quickly.) It seems a little odd using Ruby to build Java projects, but ironically I actually prefer that over Groovy. This is horrible for me to say, but I'd like Groovy to gracefully go away--it lost the Java.next race (they were stubborn about dynamic typing for way too long) and I feel the only reason it's still around are for the admittedly nice frameworks it sprouted: Grails and Gradle. The language itself is "meh", IMO. ...although it bothers me to no end that a dynamic language like Groovy had compile-time AST translation way before other (similarly mainstream) static languages like Scala. Anyway. Gradle's momentum is impressive. Perhaps I can unlearn my Groovy bias.

Communitivity 13y ago

I'm a sw engineer programming Java since 1996. I started using Maven when it first came out as the declarative build language hooked me, and became the local Maven expert. I've watched it grow with pride, and sometimes in anger. I still believe a declarative build language is best, but it won't be in XML. I suspect it will eventually be in something like OWL, whatever comes along after OWL that fixes its issues. So as of a few years ago I too moved on to Gradle and have loved it. But... Language based build systems offer more expressiveness, but that is also more rope to hang yourself with if you get someone that doesn't know Gradle well doing tinkering with your build. For example we had someone add a custom checkstyle report to an Android project using Gradle. After their edits it stopped working because of the way the Android plugin was designed, bringing the build down for several hours. I came in, rewrote the Gradle build file to workaround the issue and it worked. Then I documented to the person why it hadn't worked and what I did to fix it. As with the adoption of anything that gives you more rope to hang yourself with, it's a necessary piece of Gradle adoption to document your practices and train your team well.

twic 13y ago
"I documented to the person" - that is a euphemism i will have to remember. Yeah, I documented it to Jim. That's a documenting he won't forget in a hurry, make no mistake.

ssfsx17 13y ago

What is inherently virtuous about a build tool being pure-declarative and having no imperative impurities?

andrewaylett 13y ago
Any tool can get hold of the full state of how to build the project, then interpret it itself, rather than having to work out what the imperative code is trying to achieve.

ExpiredLink 13y ago

Do it the Maven way and you'll have no problems. Fight the Maven way and you'll end up in a mess. tl;dr Understand the tools you use.

ghostdiver 13y ago
Maven killed some great open source projects, i.e. Apache Cocoon
- ExpiredLink 13y ago
  According to the hp Apache Cocoon is based on XML/XSLT and Spring. If it failed I bet not because of Maven ...
  - ghostdiver 13y ago
    except that in Cocoon you are not forced to use XML/XSLT. Try to make sample webapp using Maven 2: http://cocoon.apache.org/2.2/1159_1_1.html http://cocoon.apache.org/2.2/1159_1_1.html I bet you will fail thanks to some random maven quirk:) Spring is just some Java library, XML/XSLT is too simple to break anything.
jebblue 13y ago
I've tried on many occasions to make Maven work with Eclipse but Maven nearly always finds a way to mess up Eclipse's excellent project management abilities. I'd say that if you just write code in an editor then Maven makes a lot of sense, if you use a powerful IDE like Eclipse then Maven becomes an unwieldy and unnecessary challenge.
ebiester 13y ago
That's fine, so long as the problem you're trying to solve is easily expressed within Maven's structure. And sometimes, expressing it withing Maven's structure can lead to very slow builds, at least within my experience. But perhaps I'm prejudiced; I hate maven, and have since my first experience with the Mvn 2 betas. You know when you see a new technology and you say, "this is painful now, but it's going to be worth it in the end?" I got the "this is painful now, and is only going to get worse as plugins depend on crazy ass behavior" feeling. From everything I've seen since, I was right.

timr 13y ago

Reading Java people's complaints about the deficiencies in their fifty different build tools makes me want to force them all to use Make.

angersock 13y ago
They typically spell it "ant".
- ExpiredLink 13y ago
  That's the main problem people have with Maven. They try to use it like make/Ant - and fail miserably.
  - VladRussian2 13y ago
    "fail miserably" would be fine. Unfortunately it is "live miserably".
- timr 13y ago
  Yeah, they misspelled it.

Randgalt 13y ago

FYI - http://tesla.io/tesla/index.html http://tesla.io/tesla/index.html