reposilite icon indicating copy to clipboard operation
reposilite copied to clipboard

Pseudo repository support for any kind of files

Open ThraaxSession opened this issue 1 year ago • 8 comments

Request details

It might be awesome to have extended webdav support, as some artifacts are only zip files. Also it would be awesome if each directory with artifacts has something like a meta.xml. Which keeps track of the latest package + hashing.

So each time a new upload was successful, it's possible to keep the track of the latest zip release. This came in my mind as I want to upload my web client to a repository. With the same advantages like a maven repo.

ThraaxSession avatar Aug 22 '22 11:08 ThraaxSession

I don't know much about webdav 🤔 It sounds a little bit complex, do you know about requirements and why do you think it could be helpful particularly in terms of Maven-based projects?

dzikoysk avatar Aug 29 '22 21:08 dzikoysk

Hi @dzikoysk Well, it needn't be webdav specially. Webdav might be really too complicated as you would save the artefacts on filesystem and expose them like remote filesystem. (davfs) But something like a common repository for zip files would be helpful. It's helpfully as developers have often various kinds of artefacts, not only jars. It would be helpful if I develop for example a client application for different kind of operating systems. I could bundle them individually but keep them together as one version. That's how I would imagine it:

Directory structure: /release/my/project/client/xxx

myclient-linux-xxx.zip
myclient-windows-xxx.zip
myclient-web-xxx.zip
meta.xml

meta.xml:

// it keeps track of the lastest releases like for maven repositories.

ThraaxSession avatar Aug 30 '22 05:08 ThraaxSession

I think this kind of feature is quite specific and dependent on given scenario - in general Reposilite allows you to upload any file atm to the repository, so such behavior should be probably implemented on the client side, just like e.g. Maven client. So client deploys not only those zip files, but also generates meta.xml (with metadata about those files and probably even more data you can configure during build phase) and Reposilite just stores it, so this kind of logic is a part of client and server stays quite generic. Not sure how you're deploying those files, but e.g. Gradle is pretty convenient solution for customizing any part of your build process, so you could probably write a script/plugin that handles it and it should work way better than any logic on server.

dzikoysk avatar Aug 30 '22 10:08 dzikoysk

The meta.xml I assume is generated by the server currently, isn't it? I would see to update this meta.xml to updated by server, not client. As the client doesn't know the current versions. Do you know what I mean? Sure, uploading isn't a problem. I could upload a bunch of files, no matter gradle or via REST. But keep track of the current files, I would assume that the server update those meta informations. Else I would need create a plugin or extension for each build system which tracks down this meta information.

ThraaxSession avatar Aug 30 '22 12:08 ThraaxSession

maven-metadata.xml files are generated by Maven client, not server, that's the procedure:

  • User runs deployment
  • Maven downloads current metadata files from repository
  • Maven reads downloaded metadata files and adds new necessary stuff about new files
  • Maven deploys updated metadata files as well as other files

Reposilite, and any other repository manager, is not modyfing metadata files as it's not its responsibility. That's healthy, because it reduces a need to "guess" what clients meant when they've uploaded specified files.

dzikoysk avatar Aug 30 '22 12:08 dzikoysk

So actually it means I would need to create a plugin for different buildsystems. That's what my ticket is about. It's not about maven here. It's about a simple routine here to upload generic files. (It can be a Reposilite/Javaline plugin)

Procedure: I upload my testicals via rest against something like PUT /api/upload/generic/{the repo}/{version}/file. It gets the file, it updates the meta.xml and as it knows which repo and version. And with GET /api/upload/generic/{the repo}/version or whatever I can retrieve the current files. With another API like GET /api/download/generic/{the repo}/{file}/{version} or even GET /api/donwload/generic/{the repo}/{file}/latest I could download it. file = 'myclient-linux'

I hope it's more clear why it doesn't work on client side. It's too generic for maven/gradle. As Flutter/Bazel/Cmake or what ever doesn't work with it.

Plus it doesn't need to be a zip file. I could upload as *.tar.gz, *.tar and *.zp. even *.exe or *.appimage or something would work. That's why it would be awesome.

ThraaxSession avatar Aug 30 '22 12:08 ThraaxSession

I feel like you're more comfortable with this topic than I am, would you like to try to prototype this as plugin? In theory you should be able to listen for DeployEvent and generate some kind of metadata file on top of that.

dzikoysk avatar Aug 30 '22 14:08 dzikoysk

I could try. :)

ThraaxSession avatar Aug 31 '22 05:08 ThraaxSession