I think Ant is lovely. Most of my projects only extend the Java SE API. I don't see the need to change to a build tool that manages third party libraries unless and until I need to use third party libraries.
Keep supporting Ant and keep the build process as trivial as it needs to be. On Wed, 21 Apr 2021 at 15:56, Will Hartung <willhart...@gmail.com> wrote: > > > 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 > >
