Bug 208213

JG01: We should create a single module with "IndexingBridgeProvider" on which versioning, ant and maven will depend. The implementation of this interface will be provided by PA. Just one api or friend-api module will be added and the original versioning bridge will be removed.

JG02: No. It does not use the threadIds to block only the changes form given thread. The thread id is used for checking that enterProtectedMode and exitProtectedMode are paired (the same thread has called enter and exit) and to assert that thread which called runProtected does not do ParserManager.parseWhenScanFinished().get() which will cause a dead lock.
So the only difference is that instead of enter|exit method the API provider runProtected which is safer as it removes form API client the responsibility to unlock the RU.

Regarding the proposed api:

>void startTransaction();
>void endTransaction();
I personally prefer the version with Runnable. We had beginTrans, endTrans in MOF. The API clients did not call the endTrans and it was real pain to find it. The runProtected in public API ensures the balanced locking. 

>boolean isInTransaction()
OK


>void addChangeListener(ChangeListener);
>void removeChangeListener(ChangeListener);
What the information is good for?


>void runAfterTransaction(Runnable)
OK. The Runnable can be a parameter of runProtected.


>It seems this would not suffice for the purposes of bug #167098, which calls
>refreshAllIndices, i.e. versioning.indexingbridge might still be needed.
The refreshAllIndices call is questionable as it not needed for OS with native listeners.
Also the VCS exactly knows which files were changed, scheduling up to date check of everything
seems to me wrong. The VCS should schedule rescan of changed files only.

(In reply to comment #1)
> JG01: We should create a single module with "IndexingBridgeProvider" on which
> versioning, ant and maven [and projectui?] will depend.
> The implementation of this interface will be provided by [parsing.api].
> Just one api or friend-api module will be added and the
> original versioning bridge will be removed.

This can work I think. I will try it.

> It does not use the threadIds to block only the changes [from] given thread.

I will document this then.

> The runProtected in public API ensures the balanced locking. 

Of course. I will check if it is possible to use this from things like Ant execution.

>> void addChangeListener(ChangeListener);
>> void removeChangeListener(ChangeListener);
>
> What the information is good for?

The above would be for use from parsing.api, in case of a semaphore-style API.

> The refreshAllIndices call is questionable as it not needed for OS with native
> listeners.
> Also the VCS exactly knows which files were changed, scheduling up to date
> check of everything
> seems to me wrong. The VCS should schedule rescan of changed files only.

Well this is beyond my area of knowledge (bug #167098) so I would leave it alone.

core-main #fc07aef4b575

Yes, the IndexingManager.runProtected really deserves better documentation.
I will update it.

fc07aef4b575 includes some improvements to runProtected's Javadoc, but you should review and update.

Integrated into 'main-golden', will be available in build *201203030400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/fc07aef4b575
User: Jesse Glick <jglick@netbeans.org>
Log: #208213: IndexingManager.runProtected from project system operations

Thanks, the updated javadoc is good.
I've only removed the:

"Also note that this call is not reentrant."

The call is reentrant, the thread ids are kept in the List so it's safe to do
IM.runProtected(()->{IM.runProtected(()->{....});})
in the inner Callable there will be 2 same thread ids in the protectedOwners list.