Contents
-
Deprecated Classes
(To be removed as it was introduced in 2.0.0-alpha-2!) This class is wrong, as it uses Resolver 1.x
bits that do interpret dependency scopes. The proper session supplier should be provided by consumer project
(Maven) that also defines the dependency scopes and their meaning and semantics, as session need to be equipped
with these bits. Session is very much dependent on the consumer project.
Definition and semantics of the scopes should be defined by consumer project. Resolver out-of-the-box
supported scopes are defined in
DependencyScopes class. Resolver is oblivious about any other scopes and their
semantics.
The use of class should be avoided, see
StringDigestUtil and file processor in SPI module.
This class belongs to consumer project. Resolver have no notion of scopes other than those defined
in
DependencyScopes class, moreover it has no knowledge about scope transformation
of dependencies to build path scopes.
This class belongs to consumer project. Resolver have no notion of scopes other than those defined
in
DependencyScopes class, moreover it has no knowledge about scope transformation
of dependencies to build path scopes.
This class belongs to consumer project. Resolver have no notion of scopes other than those defined
in
DependencyScopes class, moreover it has no knowledge about scope transformation
of dependencies to build path scopes.
-
Deprecated Methods
This method should not be used. Since version 2 Resolver internally distinguishes between artifact
update policy and metadata update policy. This method was left only to preserve binary compatibility, and in
reality invokes
RepositoryPolicy.getArtifactUpdatePolicy().
Use SPI checksum selector instead.
Use SPI checksum selector instead.
Use SPI FileProcessor to read and write checksum files.
Resolver is oblivious about "scopes", it is consumer project which needs to lay these down and
also assign proper semantics. Moreover, Resolver is oblivious about notions of "classpath", "modulepath", and
any other similar uses. These should be handled by consumer project.
Resolver is oblivious about "scopes", it is consumer project which needs to lay these down and
also assign proper semantics. Moreover, Resolver is oblivious about notions of "classpath", "modulepath", and
any other similar uses. These should be handled by consumer project.
-
Deprecated Constructors
This way of creating session should be avoided, is in place just to offer backward binary
compatibility with Resolver 1.x using code, but offers reduced functionality.
Use
RepositorySystem.createSessionBuilder() instead.