On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick <s...@pekinsoft.com> wrote:
> Explain to me, Scott, why I **need** to learn Maven and dump Ant. Ant has > served me very well all of these years and has never given me one single > bit of trouble. Speed? Ant is fast enough for me and my projects. Keeping > libraries "up-to-date"? That is just another way of saying "stay on the > bleeding edge." Why should I learn Maven and dump Ant? Explain it with > facts and reasoning, and without resorting to expressions such as "sticking > your head in the sand." > I have a project using JavaFX, JPA, CDI, and Derby. My pom.xml file lists 13 direct dependencies. The actual number of jars that get imported is closer to 50. There's a really cool project out there used to write REST based micro web services called dropwizard. To use it, you add a single dependency to you pom.xml. When your project builds, it downloads and imports about 90 other jar files. Nowhere on their site will you see this list of jar files that it requires to run. Using the IDE, with two mouse clicks, I can have not just the jars downloaded, but all of the available javadoc and source files. Once it's all caught up, I have access to all of that within the IDE. The key point is, that in the modern Java community, projects are shared using Maven artifacts. Many sites start their "quick start" instructions with "plop this dependency into your project file". From there, magic happens. Gradle relies on Maven repositories. Ivy for Ant relies on them also. I think there are other Java build tools that do also. Finally, NB, Eclipse, IDEA, and even Emacs all have first class support for Maven projects and pom files. With those pom files, all of the autocomplete works MUCH better, and painlessly. This works very well in offices with mixed development environments. Eclipse can not open a NB Ant project. NB can't open an IDEA project. All of them work with Maven projects. Maintaining the NB libraries is not a really big deal for small numbers of jar files. Even with a large number that's incrementally built up over time. But adding new projects with new dependencies that all have to be tracked down, I find, is a pain in the neck. I'm glad I didn't have to hunt down 90 dependencies to try a "hello world" dropwizard service. Now imagine updating the library lists across different IDE projects with different tools. As if teams don't have enough problems with communication and project drag. Maven absolutely has issues. It has innate complexity. It's slower than Ant for the basic Happy Path of building a project. It's reliance on internet connectivity sometimes has to be worked around. And any large team is better to jump through some hoops to set up a local repository as a cache and for local projects, which can be an infrastructure burden. But, that's it's big selling point. Maven scales much better than Ant does. And if you add Ivy to Ant, well, you have to deal with all of the Maven dependency burdens anyway. Let me give you one of my many experiences with Maven. I downloaded some > sample code today to see how someone was using a particular library. It > turned out that sample code was in a NB Maven project. I opened that > project at around 20:00, I just closed NB about 20 minutes ago. The whole > time, Maven was doing something, supposedly in the background, but it had > my CPUs up at 68% use and my memory at 82%. I have a Quadcore providing 8 > threads and 8 GiB of RAM. There is absolutely no reason that Maven should > have been pegging my system out like that for the simple little project > that I had opened. Ant certainly never does that to my system. > This is quite likely the very large repository index that NB uses being downloaded from Maven Central. This is absolutely a potential pain point. I don't have a good solution to work around it. My machine stays on (sleeps) 24x7, and I leave NB open all the time. NB will update that index once a week if you let it, and it's not an incremental update, it's a complete reload. You can disable it after the first time, and trigger the update manually. As I said before, I've relaunched at lunch time or before I leave work in the afternoon to let this happen on its own time, and not blocking me. It also bloats your NB directories. If you have your NB 12.0, 12.1, 12.2, 12.3 versions, they all have their own copy of the index. That's several GB of data, likely useless in the old version directories. NB eventually detects and helps you clean those up, but something to be aware of if disk space is an issue. > To me, it seems that more people are drawn to Maven because it tries to > take care of library management for you. However, any developer worth their > salt believes on managing that kind of thing by themselves. I have been > programming since 1983 and remember the days when a compiler was an actual > person who gathered shared libraries from various locations and manually > linked them to your application, so that your application would work > properly. I do not shun all advances in technology, but when something is > as stable and useful as Ant, I just don't get why some people just want it > gone. I use automation systems whenever they make sense for me. A lot of > things, I would rather take care of myself so that I can be sure the stuff > is the way I planned it and want it. Old school, I know, but I am who I > am... > We worked with NB ant builds and libraries for many years, but it was better for the team when we switched to Maven. The value it brought far outweighed the costs of adoption and continued use. For my personal projects, I still use it. Even if every now and then, I shake my fist at it, like anything else today. Regards, Will Hartung
