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.

Bug 69739 - Pre commit hooks
Summary: Pre commit hooks
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@versioncontrol
Depends on:
Reported: 2005-12-02 10:23 UTC by _ pkuzel
Modified: 2007-01-04 17:14 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2005-12-02 10:23:12 UTC
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 ?
Comment 1 _ pkuzel 2005-12-02 10:30:50 UTC
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 
Comment 2 Jesse Glick 2005-12-02 21:16:54 UTC
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.