>>> On Aug 12, 2020, at 4:12 PM, Tim Boudreau <[email protected]> wrote: >> 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
No argument. (Even though I will never again make a new Maven project. It has bit me in the ass one too many times and there are various things I loath about it.) > - 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). Exactly. Maven works okay when it works (and I’m not the one writing the tedious mountains of XML), but it doesn’t take long to hit a project where Maven just can’t handle what you need to do in a reasonable way. Referring to your example, I would love to see support for native projects in Netbeans via Gradle. A major project I work on is all about authoring many modules that have both a Java and a C++ component. Gradle can be much easier to use than either Ant or Maven, but it is also requires more discipline. You can get yourself into trouble. If the IDE can help that would be great. > 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: I disagree. It may enable that, but doesn’t aim for it or encourage it. Bad practices are possible with any tool. It’s similar to how you can’t code everything in Java, some projects need a native side. ‘C’ gives you the power to make a lot of mistakes, but it is often the simplest solution to a particular problem. > - basically, > whenever possible, the workflow to onboarding with a new project should be > "git clone foo; cd foo; do-the-build" I agree. Though it should be “hg clone foo”, Why make things harder than they need to be :-) Do-the-build should be one of: “ant” “make” “mvn install” “gradle” (Or similar, whatever tool is used) > IMO an > IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as > the path of least resistance. Agree. I don’t see that as a reason to not offer an excellent level of support for Gradle-based projects though. Wizards to start new Gradle-based projects with a reasonable build script that follows best practices and all that. > 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. Software engineering eventually requires the pounding of a few nails. That’s why Maven doesn’t work well for many complex real-world projects... no hammer (or its hammer is much harder to use). But back to NB... Gradle projects are for certain going to be impossible to integrate at the same level as Maven because the level of uniformity just isn’t there. It’s both Gradle’s advantage and disadvantage at the same time. That said, it’s not likely to go away either and is very popular. It should still be well supported. Cheers, Scott >>> 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
