This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
At nbusers mailing list there appeared very interesting RFE. Add client side pre-commit hooks implemented as a Ant build script target): But it's not yet sufficient. Did you remember my preceding blog concerning freedom of codestyle? Imagine now that when you use the action Commit in your IDE, it launch the target commit of your Ant file. You can customize that target to 1. execute jalopy, 2. run checkstyle, 3. run PMD, 4. run somes metrics 5. run somes JUNIT test 6. and then * refuse to commit * or accept to commit depending of the result of checkstyle, for example, or if junit tests are broken or if metrics are bad. It means that you are sure that the code you commited in the repository is well-formated, has up to date javadoc, is following your standards, ... It can only enhance the quality of code commited in the CVS repository. If VCS tasks were also Ant driven, would be easier to create pre-rules. No ?
Besides, Jesse how would it be hard to implement having a project instance in a hand. I just need to invoke well known target and check result. The idea is so compelling that I would even consider making it "hidden" 5.0 feature.
Definitely not for 5.0. Calling an Ant task from the VCS module is inappropriate architecturally. Would properly be handled by defining a new action name for ActionProvider. If defined in a project, and enabled, would be used as a pre-commit hook. Existing non-freeform project types could then bind this action to a reasonable Ant target name (documented somewhere) which you could optionally add to your build.xml; users of freeform projects could make this binding themselves (would want to add the pre-commit hook action name to the freeform customizer GUI in the Build panel for convenience and discoverability). The main problem is that ActionProvider.invokeAction defines no return value or task handle associated with the action (unlike the Ant module's API to run a target). Could perhaps invoke with a context containing a Runnable callback to be invoked by the project if and when the hook runs successfully, but this is a bit hackish and would furthermore not interact naturally with freeform projects. So would require some kind of more careful API, e.g. an optional ActionProvider subinterface returning Task (which all Ant-based project types would then want to implement). Making VCS actions driven by Ant is an interesting thought, but I doubt it would interact very well with the rest of the IDE's VCS integration.