[SAC] [OSGeo] #2978: repo.osgeo.org contains 0 byte files

[OSGeo]

#2978: repo.osgeo.org contains 0 byte files
---------------------------+------------------------
 Reporter:  jive           |       Owner:  jive
     Type:  task           |      Status:  new
 Priority:  critical       |   Milestone:  Unplanned
Component:  Systems Admin  |  Resolution:
 Keywords:                 |
---------------------------+------------------------
Comment (by jive):

 Frank I am replying to your comment as I am not sure I understand. There
 are six components in play and I cannot match your words to each
 component.

 -- upstream --

 PROBLEM REPOSITORY

 -- osgeo repository --

 GEONETWORK-CACHE (cache of the upstream problem repository)

 OSGEO-RELEASE

 -- downstream --

 MAVEN BUILD 1 (against osgeo-release)

 DOWNSTREAM CACHING REPOSITORY or MIRROR (cache of osgeo-release above)

 MAVEN BUILD 2 (against downstream caching repository or mirror)


 Replying to [comment:6 fgdrf]:

 > IMHO this ticket has two aspects:
 >
 > 1) The repository setup itself that external request might not be logged
 on osgeo instance

 I do not understand external requests that might not be logged on osgeo
 instances?

 - Do you mean how the "downstream caching repository" is setup?
 - Do you mean the setup of "geonetwork-cache" in the osgeo repository?

 > 2) the recommend setup on the repository manager that proxy osgeo
 repositories.

 There is no good answer to this as each project has a different
 constellation of jars and artefacts it requires for health and happiness.

 The "downstream caching repository" or "mirror" could choose to use
 routing rules to pick and choose what to cache from "osgeo release", or
 may have greater control to use routing rules against "geonetwork-
 release", "geoserver-release", "geotools-release" to tightly control what
 jars they obtain from where.

 The "osgeo-release" gathers up lots of sources to optimize "maven build
 1". Since maven checks *each* repository listed in the pom.xml file - it
 is much faster to have a mirror like "osgeo-release" to increase build
 times.

 For "maven build 2" a downstream repository is setting up their own
 mirror.

 > I will try this on my end. Nevertheless, why are these "wrong" requests
 lead to zero size artefacts in osgeo release repository? Is it a Nexus
 bug?

 Yes this appears to be a Nexus bug, the service that caused the issue is
 an old style maven 2 repository:
 https://raw.githubusercontent.com/geonetwork/core-maven-repo/master

 This now returns: 400: Invalid Request

 I assume it is a Nexus bug that this response is being stored as a 0 byte
 artifact.
-- 
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2978#comment:9>
OSGeo <https://osgeo.org/>
OSGeo committee and general foundation issue tracker.