That is great! Thanks for sharing with community. For GraalVM, do you mean native image? If so, OneDev does not support that, as it highly depends on reflection and byte code operations, which is very hard to adapt to native image.

It is pretty easy to use PostgreSQL via docker compose. Some OneDev users already do that.

Thanks to let me know about the Docker compose method.

I will look into that.

No, GraalVM offers many benefits, Native Image does not make sense in this case.

It improves startup time and memory consumption, but it also reduces peak performance.

Native image would not make much sense, for a long running application like native image. ☺️

Language interoperability is what I am looking for.

Mattermost, VSCode alias Monaco, and lots of other applications: Go, JavaScript, Python, Ruby, LLVM languages like Haskell, Rust and C/C++:

There are just so many options, and all that could still be delivered in one package, without external dependencies, and with very easy interop.

I think it fits quite well as a plugin mechanism for OneDev.

You know all these applications, we want to interact with OneDev, like Mattermost and Grafana?

Currently, they would be difficult to fit in.

They are written in Go, and that would make it awkward to ship with a Java application.

Via GraalVM and the WebAssembly compiler for Go, can it be consumed by Java via the WebAssembly implementation of the Truffle Framework.

The whole application gets delivered as one.

@robin I have to say I told you so, you questioned whether community instances was a good idea, I said one instance would promote more to rise, and it seems like this is another stepping stone :)

@shalokshalom Firstly, be careful, I have only had a few people use my public instance. My instance is using spare resources I have on my server, you are hosting a whole server in oracle cloud which will cost you a lot of money.

You got to bare in mind that if it does not get used it is not the fault of anyone here, you are optionally giving up your money and time to host this instance, if you are happy to do that, continue, if you are not, please stop before you waste too much of your money :)

now for your improvements:

1. No, this has been brought up already by you, Onedev is not going to exclusively endorse a single JVM, if you want to use GraalVM then thats up to you, but Onedev will most likely stay open to all JVMs (I hope Robin?)

2. When you mean default image, what you talking about, if you want to configure a different database see the docs

That is great! Thanks for sharing with community. For GraalVM, do you mean native image? If so, OneDev does not support that, as it highly depends on reflection and byte code operations, which is very hard to adapt to native image.

I would like to highlight one thing, reflections are very slow, if you want to keep onedev optimised and efficient, try to avoid reflections as they are not easily optimised and thus the JVM is severely bottlenecked by code relying on reflections.

@shalokshalom If you plan to go ahead with your community instance, thats great :)

Please do the following edits to the documentation which can be found here: https://code.onedev.io/onedev/docs

You first need to add yourself as a community maintainer, and specify what you maintain within the community, by editing the following file:

https://code.onedev.io/onedev/docs/~files/main/docs/community/community-maintainers.md

Once you have done that, you then need to add your instance to the list of community instances (please keep this alphabetical for simplicity):

https://code.onedev.io/onedev/docs/~files/main/docs/community/instances.md

When adding the instance, please ensure all values defined within the specification with a * (required) flag are met, this is to ensure that the community instance is contactable and enough information about it is provided, I wrote these rules myself thus Robin is free to overrule them seen as it is his project:

https://code.onedev.io/onedev/docs/~files/main/docs/community/instance-keywords.md

After doing this submit a PR and I am sure Robin will review it.

@shalokshalom for now I hope to keep official distribution of OneDev light with only core functionalities. It may contain integration plugins to other applications such as Mattermost or Prometheus, but will not ship those applications.

On the other hand, if some day OneDev has to bloat to include external applications for some reason, I'd prefer to go with the Docker compose apporach as docker image of these applications are battle proved...

Nevertheless, I am interested in seeing how these applications actually perform in GraalVM.

You would serverly benefit, if you would read, what others write, @polarian

@shalokshalom for now I hope to keep official distribution of OneDev light with only core functionalities. It may contain integration plugins to other applications such as Mattermost or Prometheus, but will not ship those applications.

On the other hand, if some day OneDev has to bloat to include external applications for some reason, I'd prefer to go with the Docker compose apporach as docker image of these applications are battle proved...

Nevertheless, I am interested in seeing how these applications actually perform in GraalVM.

Considering that a stark amount of people would not need Mattermost, Grafana and other plugins, is it just wise, to ship DevOne without them.

I would not change that either.

Besides integration plugins, do I see the sense for integration by a build in package manager.

So that integration is easy for the customer.

This is still music of the future, obviously.

And about the docker images: They allow you to run, and barely interact with your project.

How does a Docker image provide any form of usable API, for you?

As an example, if I want to create or close an issue from the Chat on Mattermost, I would need some kind of API.

The interaction between DevOne and an application in Go, or another language outside the JVM is something, that the old runtimes seem to make harder, as when you interact with them via the Polyglot API.

Correct?

@robin Thanks for your ongoing effort. In order to scale my instance, I consider using multiple data centers, spread across the world. In order to ensure this, it seems obvious to use distributed SQL databases.

You already added support for Postgres, MySQL and so is it possible to use Yugabyte, or TiDB.

Would you see, you have experience with those? Is it possible, to host OneDev in you experience with multiple instances on different servers and the same, shared database?

You can use the same database server to host multiple databases, with different name each by OneDev server instance.

If you share the exact same database accross multiple OneDev instance you need to sync file of each instance. It's a sort of high availability but a poor one as the database become the SPOF.

Oh I totally missed the point of free tier.

Also can I highlight nothing is free, what are you giving away in order to run this server, probably a ton of privacy as oracle will want to know everything about you in order to give you a free server.

Also Onedev has two types of plugins, ones which are distributed with onedev, and ones which are add-on. Unfortunately as the plugin would need to be directly integrated into onedev, it would need to be distributed with onedev.

Doesn't stop you from disabling it or ignoring it.

@robin Thanks for your ongoing effort. In order to scale my instance, I consider using multiple data centers, spread across the world. In order to ensure this, it seems obvious to use distributed SQL databases.

You already added support for Postgres, MySQL and so is it possible to use Yugabyte, or TiDB.

Would you see, you have experience with those? Is it possible, to host OneDev in you experience with multiple instances on different servers and the same, shared database?

You are overthinking it right now, I already said there is slow uptake of community instances, and you want to go all out geolocated datacentres across the globe for maximum redundancy and reliability, when you don't know if a single person will even use it yet.

Scale the instance as needed, and stop overthinking it at the beginning...

True. The point is, once it goes up, it's difficult to change those things.

Thanks a lot for your help, the detailed instructions about the contribution path really helps.

onedev.community is the envisioned domain

True. The point is, once it goes up, it's difficult to change those things.

Thanks a lot for your help, the detailed instructions about the contribution path really helps.

onedev.community is the envisioned domain

Nice domain, however you might want to ask Robin first to ensure the domain name does not interfere with onedev.io, as it might seem as if the community instance is hosted by Robin and not by you. There needs to be clear distinction between community maintained solutions and solutions which Robin will maintain.

Good luck with the instance :)

@shalokshalom

Besides integration plugins, do I see the sense for integration by a build in package manager.

Not sure what this means.

How does a Docker image provide any form of usable API, for you?

I guess almost all products have some form of RESTful api. Just mean that if OneDev has to package some independent application, the docker compose way should be a more reliable and easy approach. You still need to write logic to interact between different applications though, even if they are in same compose file.

@robin Thanks for your ongoing effort. In order to scale my instance, I consider using multiple data centers, spread across the world. In order to ensure this, it seems obvious to use distributed SQL databases.

You already added support for Postgres, MySQL and so is it possible to use Yugabyte, or TiDB.

Would you see, you have experience with those? Is it possible, to host OneDev in you experience with multiple instances on different servers and the same, shared database?

This will be a feature of OneDev EE.

True. The point is, once it goes up, it's difficult to change those things.

Thanks a lot for your help, the detailed instructions about the contribution path really helps.

onedev.community is the envisioned domain

Nice domain, however you might want to ask Robin first to ensure the domain name does not interfere with onedev.io, as it might seem as if the community instance is hosted by Robin and not by you. There needs to be clear distinction between community maintained solutions and solutions which Robin will maintain.

Good luck with the instance :)

Nice domain I also agree 🙃 This is your property. Just go ahead with your adventure.

This is where using package managers provided by linux distribution would be useful, allows for easy installation and removal of plugins :)

However the downside is you need maintainers who are willing to maintain for each different distribution, the base distributions you would need to support is:

• Arch Linux (pacman) - Currently maintained by me and Ben
• Ubuntu/Debian (apt) - No maintainer

Eh that pretty much makes up all of the most common distributions, most distributions are ubuntu/debian based, and then the others tend to be Arch based.

Unfortunately I am yet to be able to get pacman (arch linux) to automatically backup and upgrade the package, without manual intervention. All the Arch Team is saying is insulting onedev for using JSW and ask you to move to a different Java Service Wrapper.

I understand you want to keep onedev easy to maintain, but people refuse to support you when you make it extremely difficult to distribute the onedev package, you are using a JSW which is distributed under multiple EULA.

Is there any chance you will overturn, or provide an option to install onedev without the JSW dependency, so that people will adopt the idea of onedev, currently your JSW dependency is actually preventing people using your product.

You have to choose, userbase or ease of development, they are currently conflicting one another, and I am not too sure what to do. I have a working AUR package, but it is not the easiest to use, and requires reading the following guide:

https://wiki.archlinux.org/title/Onedev#Updating

I understand I ask I lot, but I am trying to work with you, not against you.

I assume your response would be, if you want this to be support code and maintain it yourself xD

---

I guess I've explained a lot on this to you.

To give you data: 90% of OneDev downloads are docker images. And the upgrade is just by changing tag from for instance 1.0 to 2.0

For 10% users running on bare metal, installation is just extract the tar.gz to a folder, and run it with "bin/server.sh start", and upgrade is simply "bin/upgrade.sh ". And this works on all platforms, linux/windows/mac/freebsd...

Now you tell me that you don't like this, and you want to create OS specific distribution packages. I warned that there are many pitfalls on doing that, but if you insist to try, just go ahead. Now you encounter obstacles, and complains that I am not supporting you...

If you do not like the way OneDev works, just fork it.

For this month, 97% downloads are docker images.

https://hub.docker.com/?namespace=1dev

You are misunderstanding me.

I am aware how much dominance docker has, because sysadmins are lazy. However for the bare metal installation the arch linux package works very well now, the only issue is no other packagers will help out because you use a proprietary JSW.

That is the only issue, and what I am trying to highlight. I am fully aware the difficulties with the package are my own doing, but it does not mean you can't give me feedback on it.

Currently your approach to the package is you want to pretend it doesn't exist, but it doesn't stop you saying "this works, this doesnt".

---

This problem is difficult to solve. Also JSW plays a key role in OneDev.

Also I do not want to waste my time on solving a problem that is not a problem at all.

@polarian

I'm absolutely tired reading all your longs speechs trying to explain to extremly experienced people how they have to do things the way you want. Often the wrong way.

Despite the time spent along many threads you always come back with :

• distro packages is the good way and all 97% of users using docker are lazy and doing it wrong.
• openjdk is far away better and free don't use JSW.
• you want to release a EE version, you will fail as gitlab/gitea.

Quite every issue you open is a complete waste of time trying to overcome above OneDev direction.

A large number of users have complained about the following: Me speaking too much/being to active on mailing list and IRC channels Me being "annoying" Me being "too young" and "inexperienced" Me being "narrow minded" Now I am not sure which of these are exaggerations or maybe they are all facts, but I get mixed responses from different people, some aggressive some compliments.

No exaggerations, that's true. Please make a step back and try to understand the situation.

Your behaviour is someone having a passion for IT (good) but not finding how to spent time with. So, instead of developping your own project you joining other and give advice/order.

OpenSource is a meritocracy : your work will speak for you.

If you think you're right, fork OneDev, make every change you want (packager, openjdk...) and we will see which version users prefer.

Since you are an experienced developer, Polarian, you have surely experienced already, that going for the route, that has not been taken before, is always a struggle.

There are almost always incompatibilities, and it's almost always required to work with the community.

I am using a very exotic programming language - F# - but I am doing so on dotnet.

I use a relatively exotic distro, but it is backed by Arch.

When you are interested to get something working that less people are working with, like functional programming and a rolling Linux, you are going down a path, with less options.

And the more and more you are going down that path, the less support you will get.

I use so much exotic stuff, and still, I am going for a route, that combines both modern, interesting features and compatibility with the world.

The Arch community can be difficult to work with, but I also prefer open source software.

So I see both points here. ??

I would love every project to change something to my will.

I am convinced that every project I know, could improve by listening to me.

Ultimately is the question how we reach the goal, of achieving something that most other people seem to not like.

And ultimately, it's always the case that that, what is not most popular, like an Arch package of OneDev, is something you need the help of those involved.

And if you like to bridge gaps, you will fall into the ground, if the pillars at both ends of the bridge dont stand strong.

I developed Arch packages myself, and if both the Arch community and the OneDev community are incompatible by nature, it's on you and others who are like minded, to make it happen.

FOSS is about freedom

Since you are an experienced developer, Polarian, you have surely experienced already, that going for the route, that has not been taken before, is always a struggle.

There are almost always incompatibilities, and it's almost always required to work with the community.

I am using a very exotic programming language - F# - but I am doing so on dotnet.

I use a relatively exotic distro, but it is backed by Arch.

When you are interested to get something working that less people are working with, like functional programming and a rolling Linux, you are going down a path, with less options.

And the more and more you are going down that path, the less support you will get.

I use so much exotic stuff, and still, I am going for a route, that combines both modern, interesting features and compatibility with the world.

The Arch community can be difficult to work with, but I also prefer open source software.

So I see both points here. ??

I would love every project to change something to my will.

I am convinced that every project I know, could improve by listening to me.

Ultimately is the question how we reach the goal, of achieving something that most other people seem to not like.

And ultimately, it's always the case that that, what is not most popular, like an Arch package of OneDev, is something you need the help of those involved.

And if you like to bridge gaps, you will fall into the ground, if the pillars at both ends of the bridge dont stand strong.

I developed Arch packages myself, and if both the Arch community and the OneDev community are incompatible by nature, it's on you and others who are like minded, to make it happen.

FOSS is about freedom

I am not extremely experienced, but yes I understand the struggles of creating open source software. Lack of funding and credit for your work makes it difficult to continue working on. I have had the same issues, you constantly question "what is the point of me continuing developing this", because sometimes it just feels like it is all for nothing, cause you are literally getting nothing in return.

I am aware there is obviously going to be compatibility issues, but that is why I have put a lot of effort into trying to find every way to package onedev, it has also been deployed to https://polarrepo.polarian.dev which is my unofficial Arch Package repository, which makes it easier for people to install as they do not need to clone and build the packages manually.

I have also been actively maintaining the Arch Wiki page on onedev, because nobody else seems interested in helping me out in the Arch community, got to do it myself, see Onedev on the Arch Wiki if you want to take a look.

There is nothing wrong with being an exotic developer, you are using/developing something which is unique, F# seems like a pretty cool programming language but I have never checked it out personally, I am pretty sure it was designed for data science was it not?

I may be a rigid open source developer, but I will not get in the way of people who want to use proprietary software, I currently maintain AUR packages which contain proprietary software, I personally do not use it, but others do, and there was no maintainer so I am the best they got.

I am fully aware about the two sides currently, the majority of the onedev community uses docker, which I disagree with as its so lazy method (it was designed for lazy sysadmins so what do you expect?), the source install is fine, but it can be a little annoying to keep track of, therefore the best option in my opinion is an Arch Package (or a package on any other supported distributions), Robin does not want to support it due to the high maintenance, the docker lovers swear by docker and will never use a package or source install, and then there are the couple of people in between who would like to see it happen.

The Arch package is now very stable, so I am going to request it is reinstated into the docs.

I would like to highlight I am not with the idea of FOSS, I used to and I will explain briefly why.

FOSS, or the freedom part, is controversial, it actually means freedom from proprietary software, not actually freedom.

FOSS, mainly GNU licences, are so concerned with eradicating proprietary software, they forget about they are trying to make the software community free. I am on the side of permissive, I use mainly unlicense and zlib as they are extremely permissive, unlicense has NO conditions and zlib has the condition that the software author can not be misrepresented.

GNU in the other hand takes your permissions, and uses it to ensure the software is legally impossible to become proprietary, is this truly freedom though? sure you can always see and modify the source code, but you have so many other conditions to agree to... This is why I am permissive and not freedom.

The Arch package is now very stable, so I am going to request it is reinstated into the docs.

I hope to keep the installation guide compact and clean. For unofficial installation approaches I am unable to test, I'd suggest to put on relevant community sites.

the source install is fine, but it can be a little annoying to keep track of

Have you ever tried the official bare metal installation? It is not building from source.

@polarian I created a community installer section at docs.onedev.io, and you may put archlinux installer here:

https://docs.onedev.io/category/package-installers

I also cleaned up docs a little to make it less verbose.

@polarian @shalokshalom For each content maintained by community, I'd suggest to add maintainer information following the content, just as the archlinux guide does.

And it is up to you to organize/re-write the community section, and I will be happy to merge.

I feel that listing the maintainers as a standalone section does not help users generally. So I make it explicit that for each content, who to consult.

But it is up to you to reorganize it in the way you feel appropriate.

Or add a seperate maintainers/contacters page simply listing name and contact methods. Then at the end of each content, add a link pointing to appropriate maintainer.

Sort of, but remove irrelevant information such as ArchWiki info. Just to make it compact and clean. Again it is up to you what content you put there.

I have had a lot private stuff to do, so I didn't come to this one.

Considering I will setup it correctly within the next few days - the server is ready so far, just lacks the configuration of the secondary volume and some setup of OneDev by itself, - will I pick Admins, who are ready to accept this position.

If you are interested, just say how you imagine that position to be fulfilled by your person.

Wonderful day ????✌??

How is this related?

Thanks a lot.