...
- Alternative Versioning Schemes
- Accommodating Integrator / Vendor Builds
- Platform-specific Artifacts
- Encoding Build Options into Artifact Identity
- Alternative Artifact Resolvers and Repository Layouts
| Anchor | ||||
|---|---|---|---|---|
|
...
This principle extends all the way out to cases where the build may need a copy of the artifact with debugging symbols enabled. In fact, there are so many possible build options in an average C project that it's not practical to encode this information in a simple filename. Yet it's important that the build system be able to retrieve the most appropriate artifacts given the project's declared dependencies.
| Anchor | ||||
|---|---|---|---|---|
|
5. Alternative Artifact Resolvers and Repository Layouts
There have been several requests from non-traditional Maven users (linux distribution managers, IDE/platform developers, etc.) to allow a means of artifact resolution which is dramatically different from that currently supported. For instance, when building C packages on Fedora, it would often be useful to specify a dependency which can be resolved from the list of installed in the RPM database, and use that dependency for compile-time flags. Also, when building Eclipse plugins or features, it would be useful to have an artifact resolver which could use the plugins/fragments that are already present in the Eclipse instance. Also included in these sort of exotic examples might be libraries contained within the JDK itself, like tools.jar, or in the standard extensions dir, like xerces or something.
Problem
Maven currently supports only one concept of artifact identity, with a single version scheme. Snapshot builds are the only type of artifact that can vary without varying the declared dependency in a POM, and snapshots have a concrete version format when deployed to a remote repository. Artifacts are uniquely identified by:
...