Will, You have given a very well thought out answer to my message and I appreciate that. Now, let me ask you this: do you maintain legacy systems that were built with the Swing Application Framework? If so, were you able to convert them to using Maven?
I have a couple of legacy applications that I maintain that use the SAF and I copied one of the project folders to a new location, just to see if I could switch it over to Maven and once I did so, nothing in that project worked any longer. If you happen to know of a way to make those legacy projects play nice in the Maven space, I am all ears. While I remain an "Ant devotee," The easiest workaround for dealing with libraries and teams is to simply set the project up from the very start to use a dedicated folder for storing libraries. When that is done, there is a `lib` folder created in the top-level project directory. Anytime that you or someone else on the team adds a library to the project, that library is copied to that `lib` folder. If your team is using a repository (if not, I want to know how changes are tracked ;-)), that `lib` folder is also on the root of the repository and is copied to any machine that clones the library. Also, you said, "My pom.xml file lists 13 direct dependencies. The actual number of jars that get imported is closer to 50." To me, that is not a feature, but rather it is a pain in the rear. I want to know, and I mean /*know*/, /exactly/ what my project's dependencies are. My goal when designing software is to keep external dependencies at a bare minimum. No, I do not try to reinvent the wheel in each project, but I like to have absolute control over dependencies. To that end, when using Any, I have that control. As a comparison, I have created a simple "Hello World" project that contains a single `JFrame` class, using Ant and using Maven. From the finishing of the New Project Wizard until the project was ready to be run for the first time, the Ant project took just a few seconds, whereas the Maven project took well over a minute to complete the background scanning. When I compiled them into Jar files, the Ant application weighed in at around 30 KiB, whereas the Maven application weighed in at just over 1 MiB. So, the Maven project included some "dependencies" that I did not need. I felt like I had no control at all. Having said all of that, I will say this: I am not a Luddite and am seeing the writing on the wall regarding Ant. While I will continue to use it for my projects, I am working on some things on the side, such as porting the old JSR-296 AppFramework to JDK-11 and building it based upon Maven. Taking a page from the BSAF project, I am adding features to that framework, such as a lightweight docking library (pure Java, no outside dependencies). I am hoping that the legacy projects built on the SAF will then be able to be successfully ported off of the Ant build system and into the Maven realm... Anyway, once again, thank you for your well-thought out and coherent discussion. -SC On 4/21/21 12:56 AM, Will Hartung wrote: > > > On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick <s...@pekinsoft.com > <mailto: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 >
