Fix for good DefaultTrackingFileManager #1800

[martins-avots]

@cstamas Is the usage of FileLockNamedLockFactory correct for DefaultTrackingFileManager#read?

[cstamas]

Yes it is, but observe this: #1800 (comment)

Summary:

• maven2 locked the file itself
• maven3.x continued doing the same to preserve backward compat (so until this point they could co-exist working on same local repo)
• maven3.10, if change to named locks (they do not lock the subject file, they are pure "advisory locking") this breaks

[cstamas]

Check out my counter proposal: #1814

[martins-avots]

maven3.10, if change to named locks (they do not lock the subject file, they are pure "advisory locking") this breaks

Isn't FileLockNamedLock and DefaultTrackingFileManager's basically the same type of lock aka FileChannel#lock where shared can be set freely?

So instead of if (lock.lockExclusively(FILE_LOCK_TIMEOUT, SECONDS)) {
I would do if (lock.lockShared(FILE_LOCK_TIMEOUT, SECONDS)) { for
DefaultTrackingFileManager's public Properties read(Path path) {?

For public Properties update(Path path, Map<String, String> updates) {
and public Properties update(Path path, Map<String, String> updates) { lockExclusively should still be the correct lock?

Check out my counter proposal: #1814

So this means I should get the factory like this?

    @Inject
    public DefaultTrackingFileManager(FileLockNamedLockFactory factory) {
        [...]
    }

[cstamas]

Yes, you can do that too, but there were other refactorings needed, also in same PR.

[cstamas]

@martins-avots am closing this PR, what we wanted is merged. Thanks!