I think one of the biggest mistakes in the history of NetBeans was to provide support for the JSR 296 Swing Application Framework (SAF). We should have waited until it was no longer a JSR. It should only have been supported in NetBeans once it became part of the JDK. Since it in the end didn't become part of the JDK, it was essentially dead. The problem isn't that SAF uses Ant and not Maven: instead, the problem is that you're using a framework that was planned to be included in the JDK but in the end wasn't, so is completely dead.
Gj On Wed, Apr 21, 2021 at 1:52 PM Sean Carrick <s...@pekinsoft.com> wrote: > 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> 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 > >
