Aether/New and Noteworthy
This page provides the release notes and change log for Aether. Besides linking to the Bugzilla issues resolved for a given version, we call out significant changes and new functionality here.
See our issue tracker for a list of resolved issues in 0.9.0.
There have been no significant changes since the last milestone. It is simply a release that has undergone the Eclipse release review process.
See our issue tracker for a list of resolved issues in 0.9.0.M4.
Transparent WebDAV Support
The aether-transport-http introduced in the last milestone has been extended to detect WebDAV servers and issue MKCOL requests to create any missing parent directories during uploads. Remote repositories backed by WebDAV servers are specified via ordinary http:/https: URLs, i.e. there is no special URL scheme required to enable the new WebDAV support.
Customizable Checksum Policies
In previous versions, the supported checksum policies and their specific behavior was hard-coded in each repository connector. As of this milestone, the specifics of checksum policies are controlled centrally by a ChecksumPolicyProvider. The module aether-impl ships with a default implementation of this new component that realizes the well-known "fail", "warn" and "ignore" policies. By replacing this component with their own implementation, integrators may provide their own checksum policies.
Previously, the process building the dependency graph has been silently tolerating cyclic dependencies. The presence of a dependency cycle usually indicates an issue with the component composition that should be fixed. This new version records any detected dependency cycle in the CollectResult, thereby allowing applications to report the issue to the end user.
See our issue tracker for a list of resolved issues in 0.9.0.M3.
To ease working with version ranges, the version syntax recognized by GenericVersionScheme has been extended to recognize the case-insensitive tokens "min" and "max". These tokens can be used as the last segment of a version string to denote the minimum and maximum value for that segment. For example, using the new syntax, the requirement "depend on version 2.x" translates to the version range "[2.min, 2.max]". Unlike the common attempt to achieve this using "[2.0, 3.0)", the new syntax properly includes "2.0-SNAPSHOT" and excludes "3.0-rc-1". Last but not least, a range of the form "[M.N.min, M.N.max]" can be specified more compact as "[M.N.*]".
Furthermore, a new hook named VersionFilter has been added to the dependency collection process. This hook allows clients to control which of the available versions matching a range are actually acceptable for the dependency graph. The aether-util module ships with a ready-made ContextualSnapshotVersionFilter that clients might find useful.
This release introduces a new TransporterFactory SPI that simplifies plugging in support for various transport protocols required to access remote repositories. The transporters provided by the new factory extension provide transport layer services for the existing repository connector infrastructure. More specifically, the new module aether-connector-basic provides a repository connector that employs these new transporters.
To demonstrate the new transporter SPI and simplify the codebase, most of the original repository connectors have been reworked into transporters. Consumers updating to this release need to account for the following changes when declaring dependencies:
- aether-connector-basic is required as dependency to employ any of the new transporters
- aether-connector-asynchttpclient is superseded by aether-transport-http
- aether-connector-file is superseded by aether-transport-file
- aether-connector-wagon is superseded by aether-transport-wagon
As a bonus, the module aether-transport-classpath has been introduced to enable resolving artifacts from the classpath.
Note: As part of this refactoring, the contract for repository connectors regarding the transfer listener has been revised. Instead of a global listener, a transfer specific listener is to be notified (cf. the updated API docs for RepositoryConnector).
Just like with transport protocols, implementing custom repository layouts has been simplified by introduction of a RepositoryLayoutFactory SPI. These factories can be employed by repository connectors to constructs URIs for uploads/downloads. The already mentioned aether-connector-basic makes use of the new extension to provide a flexible way for accessing remote repositores. The module aether-impl provides a concrete implementation of such a layout factory for Maven's default layout.
This milestone also features our first release of the Aether Ant Tasks, enabling users of Apache Ant to utilize Maven repositories for dependency resolution and artifact deployment. Please note that the current version of the Aether Ant Tasks only supports file:, http: and https: repositories.
This is the first release of Eclipse Aether for which a compatible maven-aether-provider exists. Said component enables users to access Maven repositories and can be obtained from the Central repository using these coordinates:
<dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-aether-provider</artifactId> <version>3.1.0-alpha-1</version> </dependency>
See our issue tracker for a list of resolved issues in 0.9.0.M2.
In previous versions, the JavaEffectiveScopeCalculator and NearestVersionConflictResolver were responsible to resolve scope and version conflicts and deliver a cleaned up dependency tree. However, the separation of scope and version handling in two isolated dependency graph transformers suffers from a conceptual flaw and caused subtle bugs regarding the effective scope of dependencies. The mentioned classes have been replaced with the new ConflictResolver transformer. This new transformer handles both version and scope conflicts and provides hooks to customize the conflict resolution. To achieve the same kind of conflict resolution as offered previously by the broken transformers, use new ConflictResolver( new NearestVersionSelector(), new JavaScopeSelector(), new SimpleOptionalitySelector(), new JavaScopeDeriver() ).
The SimpleOptionalitySelector hints at another significant fix: The optional flag now gets similar processing during transitive dependency resolution as the scope, i.e. the effective optional flag is subject to the optionality of ancestor nodes and conflict resolution. For instance, transitive dependencies of optional dependencies are now considered optional as well.
As detailed in the API docs of the ConflictResolver, the new graph transformer also supports a verbose mode. This mode can be used to obtain a dependency tree which resembles the dependency hierarchy tab in m2e.
Last but not least, early feedback suggests the new conflict resolution code executes significantly faster than the old code.
Is a remote repository with the URL "file:/whatever" accessible in offline mode? To allow clients to answer this question appropriately, the internal implementation has been refactored to centralize the offline decision in a new component called OfflineController. The default implementation of this component supports two configuration properties to address common requirements:
- aether.offline.protocols: Comma-separated list of protocols which are accessible even in offline mode, e.g. "file"
- aether.offline.hosts: Comma-separated list of hostnames which are accessible even in offline mode, e.g. "localhost"
Pre-managed Dependency Attributes
Previously, the methods DependencyNode.getPremanaged*() could be used to obtain the version and scope of a dependency before it was updated by dependency management. To reduce memory consumption for ordinary dependency resolution, these methods have been removed and their backing data is no longer recorded for each node by default. The pre-managed attributes can still be obtained via a new configuration property, see DependencyManagerUtils for details regarding its usage.
P2 Update Site
Starting with this milestone, we provide a P2 update site for Aether Core, powered by Tycho. This site provides two features, one for the binaries and another one for the sources. You'll find the relevant links on the download page.
This is the first release of Aether since its migration to the Eclipse Foundation. As such the items listed below indicate changes compared to the previous Sonatype Aether codebase.
Note: There is currently no released version of the maven-aether-provider that builds upon this release of Aether Core so this milestone release is not of direct interest to users seeking access to Maven repositories. Early adopters interested in evaluating the new codebase can find an updated maven-aether-provider at https://github.com/bentmann/maven-3.
See our issue tracker for a list of resolved issues in 0.9.0.M1.
All code has been moved into the package org.eclipse.aether and sub packages. Likewise, the group ID of the artifacts deployed to the Central Repository has changed to org.eclipse.aether.
Clean up of API
Besides the new package namespace, the API has been changed in some places to ease usage and maintenance. The list below is not exhaustive but focuses on changes where updates to client code are not obvious:
- TransferEvent.RequestType.GET_EXISTENCE was introduced to allow transfer listeners to distinguish between actual downloads and mere existence checks.
- FilteredRepositorySystemSession was removed and its usages should be replaced with DefaultRepositorySystemSession and its copy constructor.
- The properties transferErrorCachingEnabled and notFoundCachingEnabled of RepositorySystemSession have been replaced by ResolutionErrorPolicy, SimpleResolutionErrorPolicy provides a stock implementation.
- The properties ignoreMissingArtifactDescriptor and ignoreInvalidArtifactDescriptor of RepositorySystemSession have been replaced by ArtifactDescriptorPolicy, SimpleArtifactDescriptorPolicy provides a stock implementation.
- Authentication was remodeled into an interface, the new AuthenticationBuilder provides a way to obtain a stock implementation.
- RemoteRepository instances have been made immutable, RemoteRepository.Builder assists in their instantiation.
Thanks to a contributor, the JAR manifests have been extended with attributes to support use of Aether in an OSGi container. Providing an update site for Aether is an unresolved todo in our issue tracker, contributions welcome.
Support for JSR-330
The components making up the implemenation of Aether have been enriched with javax.inject annotations to support wiring by a JSR-330 compliant container. The class AetherModule helps to set up bindings for the popular Guice container. Likewise, the JARs are equipped with Sisu index files to support efficient component discovery when using Sisu.