[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 fgdrf):

 We configured https://repo.osgeo.org/repository/releases as a proxy
 repository. This was the repo with empty files which should not be there
 (we haven't deployed these internal artefacts).

 And we neared down the problem that these artefacts were requested
 internally but did not exists in our hosted repositories. Therefore these
 were request in external proxied repositories as well.

 Due to the possible bug in nexus files with size 0 were written in remote
 repository.

 Today I tried again to request a non existing artefact again and it
 doesn't appeared here

 {{{
     <dependency>
       <groupId>com.group.id</groupId>
       <artifactId>whatever</artifactId>
       <version>1.0.15</version>
     </dependency>
 }}}

 Nothing there - this is great!
 https://repo.osgeo.org/#browse/browse:release:com%2Fgroup%2Fid%2Fwhatever

 Does this scenario description help to understand what problems we ware
 faced with?

 Again, thank you for your help and clean-up.


 Replying to [comment:9 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:14>
OSGeo <https://osgeo.org/>
OSGeo committee and general foundation issue tracker.