Introducing Space Packages

Valerie Andrianova

We’re delighted to introduce Space Packages! In this post we’d like to share with you the existing features, as well as the planned features we have in store for this Space module.

First of all, what is Packages? Packages is a package repository manager. If you’ve ever heard of Maven Central, Docker Hub, or NuGet.org, then you’ll easily get the idea. In a nutshell, like these products, it lets you create your own repositories and use them to publish and share packages of various types, such as Docker/OCI images, .jar and .pom files, and others, all inside your Space instance!

While this is still a work in progress, you can already try out some of the repositories.

Repository types supported

Package repositories in Space are organization-wide entities, making it possible to share repositories between team members.

Space Packages supports (or will support) the following repository formats:

• Container registries – Storage for Docker/OCI images and Helm charts.
• Maven repositories – Maven compatible artifact storage to use in Gradle, Maven, and SBT builds.
• [not-yet-available] NPM registries – Storage for NPM packages to use in npm/yarn.
• [not-yet-available] NuGet feeds – Storage for NuGet packages for .NET developers.

Search and traceability

As a repository normally contains hundreds or even thousands of packages, it can be difficult to find exactly where a specific package resides. To address this issue, we’ve implemented powerful search capabilities to help you find packages. You can search for packages by name across multiple repositories.

Finding out who has published the specific package version and where they have it can also be a problem. Thanks to the synergized integration of Space modules to share information, it’s possible to get all the details of this information.

Repository working modes

There are three modes for working with repositories:

• Local – This is the default mode. The local repository is the main storage of your packages. You can push and pull packages, reference this repo in your IDE, and use it as you would normally use a package repository.
• [not-yet-available] Mirror – In this mode, the repository becomes a mirror of another remote repository (for example, Maven Central, NuGet.org, Npmjs.com, and so on).
  • If the mirror is set to Pull only, the repository works as a pull-only cache: When a package is not available locally, Space takes it from the upstream repo and then saves it locally.
  • If Push and pull are set, the mirror has two-way syncing with the upstream server. When you push a package to such a repo, the package is pushed to the upstream repo as well.
• [not-yet-available] Group – In this mode, the repository serves as a single entry point to the group of local and mirror repositories. Instead of specifying a number of repositories, you can specify a single URL. Not only is this convenient, but in some cases, it also improves performance. For example, Gradle has a significant drop in performance if it has to go through a large number of repositories.

Want to learn more?

The Packages module already has a lot to offer. In the Space documentation, there are tutorials on how to:

• Create Container repositories and publish Docker images.
• Create Maven repositories and publish artifacts from a Gradle or a Maven project.
• Subscribe to notifications about new package versions.

There is also lots of other information there, which you might find useful for customizing and getting more out of Space, we recommend you go take a look.

What else is planned for Packages?

1. Permissions management – Configure access permissions per repository/package name prefix to ensure fine-grained control for package owners.
2. Retention policies – Automatic cleanup of repository content, leveraging retention policies with rules like “keep packages downloaded once in the last year”.
3. IDE integration – Search by package name as well as by FQN class/method references inside the IDE.
4. Project package repositories – Create package repositories for specific projects.
5. Build tool caсhes – Create repositories for tools like Gradle/Bazel with required retention policies to store remote build caches.
6. License analysis – Check reports of the used package licenses for specific projects.
7. Vulnerabilities analysis – View the health of package dependencies for projects.

We’d really appreciate it if you would share your feedback with us about both the currently implemented functionality and our future plans:

• Post your comments here
• Post an issue to our issue tracker.

If you haven’t tried Space yet, request your invite for a free Space EAP today!

Your Space Team

Subscribe to Space Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!