Difference between revisions of "SAC:Repo"
(→Nexus) |
|||
Line 52: | Line 52: | ||
The repo.osgeo.org is currently managed as an instance of Sonatype Nexus Repository Manager as shown below. | The repo.osgeo.org is currently managed as an instance of Sonatype Nexus Repository Manager as shown below. | ||
+ | |||
+ | [[File:Nexus.png|Sonatype Nexus Repository Manager]] | ||
+ | |||
+ | == Configuration Approach == | ||
+ | |||
+ | Repository naming conventions: | ||
+ | |||
+ | * project releases (hosted) - each project manages its releases in a distinct hosted repository. They may wish to upload third party dependencies here also. | ||
+ | * project snapshots (hosted) - each project with build automation manages its snapshots in a distinct hosted repository, subject to a policy expiring artifacts after an appropriate time | ||
+ | * cache (proxy) - Upstream repositories can be cached at repo.osgeo.org to improve build times. Each external repository subject to routing policies to limit contents stored. | ||
+ | * release (group) - Gathering all releases (from multiple project releases repositories, upstream cached repositories) providing a single repository for the community | ||
+ | * snapshots (group) - Gather all snapshots from osgeo projects into a single repository for the community | ||
+ | |||
+ | Nexus stores artifacts in blob storage (presently on the file system). We are defining different blob stores for different kinds of content: | ||
+ | |||
+ | * releases - osgeo projects artifacts | ||
+ | * docker - policy will be defined in conjunction with initial projects making use of this service | ||
+ | * snapshots - subject to a policy removing artifacts after an appropriate time (currently five days) | ||
+ | * cache - isolated into separate storage so we have the option of avoid backups in the future | ||
+ | |||
+ | Routing policies: | ||
+ | |||
+ | * Routing policies have been defined to minimize the amount of artifacts cached from upstream repositories | ||
+ | |||
+ | == Users and groups == | ||
+ | |||
+ | We anticipate a very small number of users with access to this system, primarily projects steering committee members, and artificial users created for individual build processes. | ||
+ | |||
+ | * Users are added via LDAP so your OSGeo User ID is required | ||
+ | * Build processes: User is created locally on the Nexus instances with access to a project specific repository. | ||
+ | * Groups, while LDAP groups are available the small number of users has not warranted making use of this facility |
Revision as of 10:54, 7 April 2020
OSGeo provides a repository manager to support our projects in distribution of programming artifacts (see also SAC:Downloads).
Maven
How to use OSGeo Maven repository
To make use of repo.osgeo.org to access OSGeo java projects.
'Example pom.xml file
<repositories> <repository> <id>osgeo-snapshot</id> <name>OSGeo Repository</name> <url>https://repo.osgeo.org/repository/snapshot/</url> <!-- Contains releases for OSGeo projects: GeoTools, GeoWebCache, GeoServer, ... --> <!-- Includs third-party-dependences, and caches of: --> <!-- ucar (https://artifacts.unidata.ucar.edu/content/repositories/unidata-releases) --> <!-- geosolutions (http://maven.geo-solutions.it/) --> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>false</enabled> </releases> </repository> </repositories>
Maven Repository Structure
Instructions for OSGeo Projects
OSGeo Projects (and community projects) are encouraged to make use of the repo.osgeo.org for releases:
For projects running a build system (jenkins, GitHub actions) you may also set up a snapshot repository for your team.
You should also be able to use your project's releases repository to synchronize your content to maven central.
Docker
We are seeing volunteer projects to test out the docker infrastructure and define best practices for the community.
Initial structure is being used to support the GeoServer project CITE automation activity:
Nexus
The repo.osgeo.org is currently managed as an instance of Sonatype Nexus Repository Manager as shown below.
Configuration Approach
Repository naming conventions:
- project releases (hosted) - each project manages its releases in a distinct hosted repository. They may wish to upload third party dependencies here also.
- project snapshots (hosted) - each project with build automation manages its snapshots in a distinct hosted repository, subject to a policy expiring artifacts after an appropriate time
- cache (proxy) - Upstream repositories can be cached at repo.osgeo.org to improve build times. Each external repository subject to routing policies to limit contents stored.
- release (group) - Gathering all releases (from multiple project releases repositories, upstream cached repositories) providing a single repository for the community
- snapshots (group) - Gather all snapshots from osgeo projects into a single repository for the community
Nexus stores artifacts in blob storage (presently on the file system). We are defining different blob stores for different kinds of content:
- releases - osgeo projects artifacts
- docker - policy will be defined in conjunction with initial projects making use of this service
- snapshots - subject to a policy removing artifacts after an appropriate time (currently five days)
- cache - isolated into separate storage so we have the option of avoid backups in the future
Routing policies:
- Routing policies have been defined to minimize the amount of artifacts cached from upstream repositories
Users and groups
We anticipate a very small number of users with access to this system, primarily projects steering committee members, and artificial users created for individual build processes.
- Users are added via LDAP so your OSGeo User ID is required
- Build processes: User is created locally on the Nexus instances with access to a project specific repository.
- Groups, while LDAP groups are available the small number of users has not warranted making use of this facility