My 2c: - Ant and Ant-based projects are never going away, the same way that Makefiles are never going away - even if nobody uses them for new projects anymore, the need to interoperate with legacy code will not disappear - I'd be in favor of making Maven projects the default thing that's pre-selected when users create a new project, and updating tutorials to focus on it - I don't think Ant makes sense to push people towards for new projects - Maven is here to stay. Yes, it's slower than Ant, but as hardware gets faster, that is less and less relevant. And probably there are tons of optimizations that could be done to Maven to make it much faster, so maybe that's a place to contribute if it annoys you. - Gradle is neat; the fact that it targets native build systems as a first-class thing is a really good thing (ever tried to incorporate building some C libraries into a Maven project build with a bunch of Jenkins slaves on different OS's and bundle the artifacts? I have. It ain't pretty). - However, in terms of ease of setup - say, you're a new developer on a large existing project - how much coaching is it going to take from the *one* person who understands the build system (because there always is one, and rarely more than one) to get your system set up to build things? Gradle's scriptability aims the evolution of a project's build squarely at the bad old days of needing magic properties files in special locations, and things like that: https://timboudreau.com/blog/maven/read - basically, whenever possible, the workflow to onboarding with a new project should be "git clone foo; cd foo; do-the-build"
I once chatted for an hour or two with Hans Doktor (gradle creator) in their office in San Francisco - it could be summed up as Me: "You're kind of encouraging people to engage in practices that are known to cause long term problems"; Hans: "Yup, and our customers like it." The bottom line from my perspective: If you have a cohort of people that are really into hitting themselves in the head with hammers, you can make good money selling helmets and head pillows to make that practice cause less harm - and if your goal is to make money, it's probably smart business to do that. If your goal is to improve the state of the art of engineering so that there are less people in the world who ever want to hit themselves in the head with a hammer, head-pillows probably aren't your thing. IMO an IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as the path of least resistance. If there are a lot of head-hammer-hittters out there, maybe supplement that with some head pillows, but don't hand them the hammer. -Tim On Mon, Aug 10, 2020 at 12:06 PM Will Hartung <[email protected]> wrote: > Ant has been the historic underlying build tool for Netbeans projects, but > over the years, not only has NB been a very good companion with Maven, > Maven is also much more popular industry wide. > > There was a comment on the user list recently about Java FX, and one reply > was, paraphrasing, "the best way to use Java FX was to use Maven". > > I was also looking at the legacy NB Platform tutorials, which use Ant, but > certainly need some updating. > > But that brought the question. Should one style of build be promoted over > the other, are both systems "faithfully and fully supported", or is Ant > going to perhaps slowly die on the vine of disinterest? > > Is there any internal mandate of ensuring compatibility between the two > build system, especially in terms of ensuring high level things like > wizards and whatnot work for both systems? If someone adds a new feature, > contrived, "Create a Microprofile web service", is the project obligated > (as much as it's obligated to do anything) to create a wizard for both Ant > and Maven, or is it acceptable to only use one mechanism? > > Just curious if there's any formal position on the two systems and their > status within the NB environment today. > -- http://timboudreau.com
