Class HashingNameMapper
- java.lang.Object
-
- org.eclipse.aether.internal.impl.synccontext.named.HashingNameMapper
-
- All Implemented Interfaces:
NameMapper
public class HashingNameMapper extends java.lang.Object implements NameMapper
WrappingNameMapper, that wraps anotherNameMapperand hashes resulting strings. It makes use of fact that (proper) Hash will create unique fixed length string for each different input string (so injection still stands). This mapper produces file system friendly names. Supports different "depths" (0-4 inclusive) where the name will contain 0 to 4 level deep directories.This mapper is usable in any scenario, but intent was to produce more "compact" name mapper for file locking.
- Since:
- 1.9.0
-
-
Field Summary
Fields Modifier and Type Field Description static java.lang.StringCONFIG_PROP_DEPTHThe depth how many levels should adapter create.static intDEFAULT_DEPTH
-
Constructor Summary
Constructors Constructor Description HashingNameMapper(NameMapper delegate)
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description booleanisFileSystemFriendly()Returnstrueif lock names returned by this lock name mapper are file system friendly, can be used as file names and paths.java.util.Collection<org.eclipse.aether.named.NamedLockKey>nameLocks(org.eclipse.aether.RepositorySystemSession session, java.util.Collection<? extends org.eclipse.aether.artifact.Artifact> artifacts, java.util.Collection<? extends org.eclipse.aether.metadata.Metadata> metadatas)Creates (opaque) names for passed in artifacts and metadata.
-
-
-
Field Detail
-
CONFIG_PROP_DEPTH
public static final java.lang.String CONFIG_PROP_DEPTH
The depth how many levels should adapter create. Acceptable values are 0-4 (inclusive).- See Also:
- Constant Field Values
-
DEFAULT_DEPTH
public static final int DEFAULT_DEPTH
- See Also:
- Constant Field Values
-
-
Constructor Detail
-
HashingNameMapper
public HashingNameMapper(NameMapper delegate)
-
-
Method Detail
-
isFileSystemFriendly
public boolean isFileSystemFriendly()
Description copied from interface:NameMapperReturnstrueif lock names returned by this lock name mapper are file system friendly, can be used as file names and paths.Note: The fact that name mapper is "file system friendly" means ONLY that names it produces CAN be used as file names and paths. Still, it does not mean they will work with ANY file based locking, as for example
FileLockNamedLockFactoryexpects names as string encodedURIs. The only name mapper doing it isBasedirNameMapper.- Specified by:
isFileSystemFriendlyin interfaceNameMapper
-
nameLocks
public java.util.Collection<org.eclipse.aether.named.NamedLockKey> nameLocks(org.eclipse.aether.RepositorySystemSession session, java.util.Collection<? extends org.eclipse.aether.artifact.Artifact> artifacts, java.util.Collection<? extends org.eclipse.aether.metadata.Metadata> metadatas)
Description copied from interface:NameMapperCreates (opaque) names for passed in artifacts and metadata. Returned collection has max size of sum of the passed in artifacts and metadata collections, or less. If an empty collection is returned, there will be no locking happening. Never returnsnull. The resulting collection MUST BE "stable" (always sorted by same criteria) to avoid deadlocks by acquiring locks in same order, essentially disregarding the order of the input collections.There is no requirement of any kind of "parity" between input element count (sum of two collections, that is) and output collection size, just the returned upper size limit is defined (sum of the passed in two collections size). If returned collection is empty, no locking will happen, if single element, one lock will be used, if two then two named locks will be used etc.
Note: name mapper must not use same string for artifacts and metadata, so even the simplest possible implementation like
StaticNameMapperuses two different static strings.- Specified by:
nameLocksin interfaceNameMapper
-
-