Maintainer wanted?

[lefou]

Coursier is a project used by many tools, including many important build tools for the Scala ecosystems (like sbt, Mill and Scala CLI).

I think maintenance of this repository is understaffed. Issues often don't see comments from a maintainer, even when one is explicitly requested. Pull request are ignored. The tooling is rather complicated making it hard to encourage contribution. Documentation is scarce but asking for help isn't very fruitful.

From looking at all these signs and also from personal frustration I cumulated with this project over time, I strongly suggest to open the project to additional maintainers. Add some prominent notice in the project's Readme and add some maintainer-wanted tag to the project. Give some former contributors merge rights, so they can review and merge those more trivial automated pull requests for version updates and documentation updates right away instead of waiting and hoping.

Also the build tooling is currently rather complicated. It uses git-submodules, making it hard to create branches or extend test cases. This is partly because this projects has multiple centers of gravity. Beside the core library for dependency management it contains also some cli tools to manage application and it provides some native runners/launchers. The latter makes the build complicated, but the former is more critical for the Scala ecosystem. So, in my opinion, splitting coursier and cs should be considered.

I'm writing this not to blame anyone, but to help and show a way forward for the better of all. To remove some pressure from existing developers and maintainers but also to serve the community and make contributions easier. It's ok to change focus. It's ok to not spend all night and spare time for a single open source project. It's ok to not work on some feature one random guy on the internet just requested. But it is fair to expect some reaction, even a "no" is better that the void. I'm sure there are others who want to help. So let's welcome them.

[tgodzik]

I will try to take a look at some PRs, but I don't feel confident about the coursier codebase enough. You are right that we need to pick up the slack here, so if anyone wants to help out I am sure we can talk @alexarchambault about it.

[carlosedp]

I agree. In addition to this, I believe the JVM index should be considered as well (https://github.com/coursier/jvm-index/).

Recently @ckipp01 and @alexarchambault do their best to keep things running.

[sideeffffect]

Regarding the jvm-index, maybe we don't need it at all, now that DiscoAPI is available: foojayio/discoapi#38
Also TypeLevel is maintaining its own version of jvm-index: https://github.com/typelevel/jdk-index /cc @vasilmkd
I'm not sure if it's sustainable if each Scala sub-community maintains its own variant of Jabba's index. Jabba is dead. Maybe we all should migrate to some other well supported and working solution, like DiscoAPI, so that we can focus on the Scala-specific issues (which JVM index is not).

[lefou]

• Cleanup git submodules: Review and replace use of git submodules #2985

[lefou]

I will try to take a look at some PRs, but I don't feel confident about the coursier codebase enough. You are right that we need to pick up the slack here, so if anyone wants to help out I am sure we can talk @alexarchambault about it.

@tgodzik I could help with some PRs as well, if someone gives me the required access rights. I don't plan to work intensively on the code base, though.

[tgodzik]

I think that needs to be @alexarchambault I can't give rights in the repo.

[lefou]

I would love to read a comment from @alexarchambault on this topic. As the BDOL of coursier, could you please provide some clarification?

[alexarchambault]

@lefou About the discoapi stuff?

[alexarchambault]

For discoapi, I think the main reason it's not used directly from coursier is that the way the coursier cache works doesn't make it easy to cache API requests such as those of discoapi (with query parameters, …) Downloading the current index works fine OTOH (it's handled like a "changing" artifact, like those on Sonatype snapshots).

But discoapi could totally be used to build the index, instead of the ad hoc code that we have to check the various JVM distributions.

[lefou]

@lefou About the discoapi stuff?

No. I meant the original topic.