Community
Participate
Working Groups
It would be benefitial to allow 3rd parties to participate in a commit. The types of participation include: 1) Pre-commit resource modification (e.g. code formatting, organize imports, build dependant libraries, etc). 2) Comment validation 3) Post-commit notification
*** Bug 41433 has been marked as a duplicate of this bug. ***
*** Bug 50341 has been marked as a duplicate of this bug. ***
No time for this in 3.1
*** Bug 128151 has been marked as a duplicate of this bug. ***
There is currently no plan to address this item.
Created attachment 85709 [details] Possible API for subscriber operation listeners After seeing that there has been continuous demand for a way to participate in subscriber operations since 2002, I think that a dedicated API for this would be a good solution. https://bugs.eclipse.org/bugs/show_bug.cgi?id=24882 includes a pretty good account of some of the considerations. However, it only addresses validation. My suggestion only contains a programmatic API so far, though some kind of extension point might also be useful. I've attached some API examples: ISubscriberOperationListener, ISubscriberOperationValidator and ISubscriberOperationEvent. The general ideas: 1) A way to participate in subscriber/repository/team operations at three different stages. a) right at the beginning, after it is clear which resources might be part of the operation (which means after LMI resource mappings have been taken into account) (these resources are part of the operation unless the user removes them in the commit dialog). In case of a commit this happens before the user has entered a commit message. This allows a validator to object to the operation without the user loosing the commit message. b) right before the actual operation is performed. In case of a commit this happens after the commit dialog has been closed. c) right after the operation was performed. Preferably before resource change events are sent out for locally modified files (i.e. due to an update operation). 2) a way to object to the operation at 1a) and 1b) with an error message which will be displayed to the user. This is pretty much what BUG:24882 was proposing. 3) a way to modify workspace resources at 1a), 1b) and 1c). Potential use cases: A) Doing some integrity checking of files before allowing a commit/check-in (i.e. style guides, syntax checking, locking, ...). B) Doing some integrity checking of the file selection for a specific operation (i.e. resource X may not be part of the operation unless resource Y is also part of it (similar to LMI), resources of type Z may not be added to the repository, ...). C) Doing some integrity checking of commit comments before allowing a commit/check-in (i.e. style guides, verifying bugtracker ids, ...) D) Automated modification of resources prior to checkin (i.e. source reformat, updating special data files which are part of the commit, updating databases, ...). E) Automated actions after an operation (i.e. tagging all affected resources with a specific tag, reparsing data in resources which were modified by the operation, updating databases, ...) This is of course only a very early draft and I've probably forgotten a couple of things. But I believe that it would be able to provide a solution to a number of bug tracker requests which are currently stalled in state LATER. Greetings Hans Meyer
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
