I could not agree with you more. Getting to a stable release management process from ant requires a lot of maven learning, some amount of prototyping and substantial training efforts to get the entire process operationalised and internalised.
Unless one is clear why one wants to move to maven and what benefits are being hoped for it is probably better to stick to ant.
I believe one of the ways to increase the probability of making it work is to spend some spare time prototyping it, optionally demonstrating the results to those who (if) might be required to sign off on your additional efforts, getting the entire process sufficiently working with reasonable documentation including the various settings required to initialise a developer workspace and a clear illustrative explanation (even if it is 5-10 bullet points) of what will improve before attempting to operationalise the process on a broader scale.
In my experience the movement to maven substantially improved the build quality and reduced the release risks. However the costs were substantial and the benefits justified them a few times over. The process of operationalising maven across a large development team (I introduced it across nearly 100 developers) is in itself a large effort which should get planned out.
Everything said bad about maven is usually true. There is no love for maven, only love/hate. I still use and promote maven for everything I can, and I hope that by 2015 it will prove to be a great and no longer hated project. Well, maybe 2020.
Main thing is not whether maven is the best standard build, but which standard build do you promote ? Ant and any other non-standardized builds mean make work forever, no matter how great it is.
If com.sun.javahelp in nbbuild is causing problems, file a bug in nbbuild to have it be removed – there is probably some other workaround. Best would be for the original bug in JH to be fixed and then we would bundle the new release.