You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@archiva.apache.org by "Martin Stockhammer (JIRA)" <ji...@apache.org> on 2019/03/10 15:25:00 UTC

[jira] [Closed] (MRM-1935) make table of contents downloadable

     [ https://issues.apache.org/jira/browse/MRM-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stockhammer closed MRM-1935.
-----------------------------------
    Resolution: Won't Fix

The artifact resolution is completely defined by maven and, if there are other repository types in the future, by their specific implementations. We are just using their libraries or implementing the specified protocol.

Improvements for the maven artifact resolution protocol should be directed to the maven project.

> make table of contents downloadable
> -----------------------------------
>
>                 Key: MRM-1935
>                 URL: https://issues.apache.org/jira/browse/MRM-1935
>             Project: Archiva
>          Issue Type: Improvement
>          Components: repository interface
>            Reporter: rupert thurner
>            Priority: Major
>              Labels: performance
>
> linux package management tools like debian apt, redhat dnf, or archlinux pacman consume binary repositories efficient since long, by first downloading a table of contents, and then calculating what to update locally.
> it would be great if apache archiva could have a similar interface giving the necessary info about its contents in one go. it is stored anyway, says this documentation:
> https://archiva.apache.org/docs/1.3.6/adminguide/consumers.html
> this then can be used by maven, gradle, etal plugins to more efficient calculate dependency retrieval. especially in the case of version ranges, snapshots, as well as "shrinkwrap" as node package manager calls nailing down the effective versions used for a build. currently in the default setting maven is pushing an artifact repository really hard when resolving version ranges, while even my phone would have 4 cores and quite some bandwith to properly calculate this in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)