Thanks for the input guys. I'm not trying to start a "build system holy war" here, just a general discussion on the merits...
I acknowledge this is not something that would be done overnight (i.e. long term project)... A few thoughts below (EB>)... Eric Bresie ebre...@gmail.com On Sat, Jan 7, 2023 at 2:24 PM Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > > On 1/7/23 08:47, Matthias Bläsing wrote: > > Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie: > >> That is a bigger philosophical/paradigm change here. Are there any > >> longer term plans to migrate the Netbeans codebase build from ant to > >> something other (Maven or Gradle)? > EB> I want to say up front and agree with others, that ant has done well in this context > > I have to ask: What problem do you try to fix? Sure when the build is > EB> The problem is usage of an "older build" system instead of leveraging a new build system as is common in java ecosystems. EB> For example, from the original thread On Sat, Dec 31, 2022 at 11:18 AM Ernie Rael <err...@raelity.com> wrote: > My solution, considering that ant is essentially deprecated in NetBeans, was to convert projects to Maven or Gradle. EB> I know this is probably more in context of "creating new projects" as opposed to existing projects but still when the trend in usage in the IDE is to "not use ant" and/or this functionality is deprecated, it seems then an alternative may be a way forward. EB> In the same way, why update Netbeans code base to use a newer java version and not just stick with an older one? Here I assume it's to adapt to the changing ecosystem and to accommodate benefits of new features and not get stagnant. > converted to another build system the problems will magically go away. > > Except they don't. Gradle has its own set of WTF elements, the same is > > true for maven. EB> I agree as with any system, they all have their quirks and idiosyncrasies. Ant does as well. EB> If migrated to another system then there would be a lot of up front growing pains to get over EB> I never said a migration would be doable overnight (i.e. did ask for a "long term plan"), that was kind of why I suggested a "phased" approach doing smaller batches. > Well, I have a long term plan for that (doing a Gradle migration). This > is not that easy. NetBeans build is an > incredible peace of art. Replacing that with something else is hard, > especially in the core platform. I had some wins, being able to compile > the platform cluster with Gradle, though compiling is just one thing, > and that's probably on the easier side. > > It is still in my mind, I see benefits of that effort. > > Though I have to admit, that what we have with Ant is good enough. Until > someone really put the effort, and proves that it could be done, we > shall not make a move. > EB> Tim converted over a lot of the "contrib" plugins previously so I think in theory it's possible...but as mentioned it would require a lot of work. Not sure if maybe he had any netbeans-tools or other mechanisms out there to help in transition. > > There are three things missing before changes could be done: > > > > - arguments why it is benefical to switch > EB> Ant is an older build system with the current java development ecosystem moving more towards other build systems. EB> Maven (and Gradle; going forward will reference Maven but can still include Gradle as well) established a common convention for project development across java ecosystem EB> Maven provides built in dependency management capabilities (I know ant may provide this indirectly with Ivy or the build infrastructure leveraging the "external/binary-lists"; but these are kind of "patched on" instead of internal to the build systems) EB> Maven provides a plugin mechanism that provides a wealth of useful code quality, security, test, assembly, and related functionality. EB> Maven provides the means to monitor dependencies versioning (i.e. can identify newer versions available, can identify dependencies with security issues in need of updates, etc.) EB> Maven, as with Ant, are "Apache" projects so leveraging this is always a win-win for the Apache organization > - preparations to counter all possible "what ifs" > EB> I'm not 100% sure what these "what ifs" might be but will try and think of a few EB> * What if some of the internal ant logic / targets do not migrate easily? EB> -> I would assume initially some of the "ant - maven" plugins may allow continued usage of existing ant build configuration and over time the individual portions can be migrated in phases EB> -> In the event of something not fully accounted for, then may also be able to further expand existing nb maven plugin adding additional goals / functionality as needed > - someone who takes up the fight and does the work > EB> Yes that is the big hurdle. My main reason for bringing it up was to see if anyone has started thinking of this. EB> Given my limited time (I'm having a hard enough time developing my python plugin) and lack of expertise in the historical ant build I'm aware that while I may be able to help some, not sure I'm necessarily the best...we all have our day jobs... > What is IMHO not a solution is a half migration, creating a hybrid > > build using ant and gradle/maven. This was done by liferay and IMHO it > > is a failure (oh for fun they also did not use plain gradle, they > > patched their chosen gradle version...). > EB> Yeah I can see that as being another hurdle. EB> My thinking was to phase it in, initially (1) leverage the ant-maven mechanism at the starting point (2) transition small clusters/projects over time (3) when all have transitioned then deprecate the ant-maven plugins and leverage full maven usage. If work stops mid way then yes that risks a "half migration" > > Seriously: If you just want unittests, go with the existing solution. > > If the pain is to high, add support for Junit 5, and if you want a > > lifetime job, switch build systems. > +1 on that one. > That is another problem for another discussion. I figured the build system migration discussion was out of context of that JUnit discussion which is why I moved it here.
