Reposilite 4.x wishlist about reposilite HOT 13 OPEN

Since it seems like the UI is going to be majorly reworked: thoughts on adding "looks at least somewhat decent on mobile" to the list? (especially the admin interface, so admin stuff can be done from a mobile device)

from reposilite.

The only thing I'm missing is an indexer+search built-in.
That's it :)

from reposilite.

also, one note: you mentioned using jte.
for me personally, jte is kinda okay-ish. I'd just like to add freemarker as a suggestion for a templating engine to consider.
there's also thymeleaf, which I've been using for my personal site. the experience has been okay-ish (solonovamax/solonovamax.gay if you wanna look at how I do stuff. kotlin + ktor.), but there have been a few kinda jank-ish parts, but other than that it's been nice.

from reposilite.

Since it seems like the UI is going to be majorly reworked: thoughts on adding "looks at least somewhat decent on mobile" to the list? (especially the admin interface, so admin stuff can be done from a mobile device)

Sure, the mobile support should be way better there. In current UI, it's mainly blocked by the tabs & jsonforms libraries, but it's a minor issue, so I didn't decide to invest my time into it for now.

I'd just like to add freemarker as a suggestion for a templating engine to consider. there's also thymeleaf, which I've been using for my personal site. [...]

When I'm thinking about a desired stack for a new frontend, I want to cover these 3 crucial requirements:

1. Get rid of a translation layer between backend and frontend (optimized template engine)
2. Avoid covering with JS basic CRUD operations (frontend framework that covers the most common boilerplate code)
3. Interface should become a part of the plugin api, so it'll be customizable to some degree (some sort of a component system)

The main reason behind JTE choice is performance - it provides a compilation mode, where it generates classes for all template components:

This + a possibility to implement Node-like hot reloading makes it a good candidate. It has some issues tho - writing a JavaScript code inside a template might be a bit painful. Even if HTMX/Unpolly/something similar would cover most of the features, there are still some side cases, when we may need to cover with JS. Raw JS/state management is kind rough, so we could try to utilize something like Preact locally, for some specific features.

from reposilite.

The only thing I'm missing is an indexer+search built-in.
That's it :)

I was working on that for a bit as a plugin sometime ago, and may continue it one day™ (or I might just forgor again)

from reposilite.

Maybe not too related to Reposilite. But what about an integrated docker registry?

from reposilite.

Yes, the Docker registry would be absolutely great. Unfortunately, it requires a lot of work, as the specification seems to be quite complex - there's an issue for that:

• #1618

It'd be nice to document all things we need to do (from specification perspective), so later on we could try to estimate if we'll be able to do that or not.

from reposilite.

Maybe not too related to Reposilite. But what about an integrated docker registry?

There is already Harbor for that, so I don't think it is strictly necessary. I do appreciate Reposilite's focus on providing great light weight solution for hosting Maven repositories.

from reposilite.

Yeah you're right. There is enough software which is already capable of providing a registry and reposilite should stay simple-ish

from reposilite.

I'd like to see support for byte ranges. I want to use reposilite as a simple arch mirror, and arch is complaining about failed downloads.

from reposilite.

Maybe not too related to Reposilite. But what about an integrated docker registry?

There is already Harbor for that, so I don't think it is strictly necessary. I do appreciate Reposilite's focus on providing great light weight solution for hosting Maven repositories.

Well, yes and no. These days, you're often distributing JVM apps as containers, so it'd be kinda nice to have it supported at some point - I could even distribute Reposilite itself there. Of course, it can't be considered as the new main target, because we don't have enough resources to compete with dedicated tools, like e.g. Harbor. Hopefully, something like that should be possible to implement purely as an optional plugin.

I'd like to see support for byte ranges. I want to use reposilite as a simple arch mirror, and arch is complaining about failed downloads.

It'd be nice if you could submit a new issue with a bit more detailed description. As long as we don't aim to support arch itself, supporting http range requests probably could be a thing.

from reposilite.

One thing I would like to see is the ability to customize the appearance

from reposilite.

yeah, the ability to provide your own css styles/themes would be quite nice

ie. use the default frontend, but just have some customized css (ie. to make the frontend a bit less "harsh")

also here's a few misc. things:

1. smth I thought of a while back that would be nice is: the ability to store cached files from a proxied/mirrored repository in a separate location.

   so, for example, the contents of the releases (that have been uploaded directly to the repo) repo could be stored in repo/releases.
   but then, say you're mirroring foo.com and bar.net (and reposilite is configured to store those artifacts)
   then, the artifacts from each of those would be located in smth like mirrors/releases/foo.com and mirrors/releases/bar.net.

   with this, you'd also be able to provide the following things:

   • add a badge on remote artifacts/modules to indicate they're from a mirror (& maybe which mirror they're from?)
   • allow administrators to set storage limits on mirrored artifacts and use smth like an LRU policy to discard old cached artifacts.

2. the ability to change the name of the repository provided in the generated "repository details" for maven, gradle kotlin, gradle groovy, and sbt. (eg. I'd like the "name" to be smth specific rather than what was generated, as well as using specific capitalization, etc.)

3. since you're looking at making the frontend part of the plugin api, should a search plugin be added to the roadmap? if it is, I could start that one thing I was working on a while ago with maven-indexer back up.

4. funny numbers: it would be cool if the statistics showed more information. for example:

   • a list of artifacts by popularity (eg. "here are the top 10 most downloaded artifacts in [time interval]: this artifact has been downloaded 123 times in the past [time interval]"
   • also maybe aggregate stats information, such as which modules have the most downloads, which versions of a certain module have the most downloads, etc.
   • showing shit like how many of the downloaded artifacts are from mirrored repos or not (ie. "123 downloads from the local repo, 123 downloads from cached mirrored artifacts, and 123 from uncached mirrored artifacts)"
   • which mirrors are the most "popular"? (eg. "123 downloads from mirror foo, 123 downloads from mirror bar")

   unsure if this might be better suited for just sending that data to prometheus and using grafana for this, though.

5. minor change to the badges api: support for different styles (see: https://shields.io/badges), eg. flat, flat-square, plastic (current), for-the-badge, and social.

6. increased visibility of metadata via a dashboard for a specific version. eg. when clicking on a specific version of an artifact, it will list (all of this is in the pom.xml)

   • the name (which may be different from the module name. see: the name field in the POM)
   • if it is a snapshot (some repos could be used to store versions & releases)
   • the description
   • the author/developers (+ contributors?)
   • the license(s)
   • the issues/repo url
   • the inception year
   • the dependencies

7. the ability to have "repository overlays" or to "inherit repositories".
   eg. let's say I have snapshots and releases. when a user adds the snapshots repo and attempts to fetch a version from it, but said version does not exist in it (or any of its mirrors), it would be nice if it then went and checked if it existed in the releases repo. so, snapshots falls back on/inherits from/is an overlay on top of releases.

~ edit: merged both comments / @dzikoysk

from reposilite.