Surely the issue with any feature or function or tool is whether there is sufficient Dev support to fix emerging bugs, properly adapt to latest versions of Java lang, JFX, JLink etc and answer tricky questions from users.
If Ant Dev expertise and time is getting harder to find it makes sense to plan a migration to a new preferred build tool(s) for new projects and new NB-IDE users. Assuming an easy to use alternative is available, labelling Ant projects legacy or deprecated might be all that is required for now. Keep Ant support running and when dev support availability falls behind the bleeding edge put a warning somewhere obvious to users when creating new projects or migrating to an unsupported versions of Java lang, JFX, Jlink etc. Is Ant at that stage? I don't know because I don't develop often enough. Any problems always come as a surprise. I take these problems, language advances and the terminology that enters over time as the usual friction in getting a quick programming job done. Big thank you from me for all providing support. On Wed, 21 Apr 2021, 08:26 Wayne Gemmell | Connect, < wa...@connect-mobile.co.za> wrote: > On Wed, 21 Apr 2021 at 06:32, Sean Carrick <s...@pekinsoft.com> wrote: > >> Actually, I have always been of the philosophy that "if it ain't broke, >> don't fix it." This seems to be a philosophy lost in today's modern world. >> Your comments show your bias toward always being on the bleeding edge of >> technology. Personally, I do not care what anyone chooses to use for a >> build tool or a programming language. What gets to me is that someone (or >> group of someones) somewhere decides that a certain technology is "too >> old", so they are wanting to kill it. It does not seem to matter that there >> are hundreds, thousands, or millions of people who use that specific >> technology throughout the world. They just decide it needs to be killed and >> everyone should just get on-board with their decision. >> > Ant may not be broken but when something does go wrong it's almost > impossible to debug. That said, it may be the obscure Netbeans > implementation that is the issue, not Ant itself. > > Another issue is that you can't keep it in version control and deploy to > multiple team members very easily. Minor filesystem differences make that > sort of thing impossible to do out of the box. > > Searching out the correct version of a library when spinning up someone > elses project is also ridicuiously difficult. Especially if the author > included sim links instead of the actually jar name with the version in it. > > Being old school myself I remember getting a coffee while my 486 booted so > as long as I expect Maven to take a while then it isn't an issue, not > knowing you will need to wait is a bit disconcerting. > > All that said, I'm not actually advocating for Maven, I'm just at the > "anything but Ant" point of my life. The hours I've spent dealing with that > obscure crap are hours I can't get back. > > Wayne >
