Maven central

[Bixilon]

How about publishing the library to maven central? With all dependencies?

2 more things that go in that direction:

• lwjlg as just build dependency?
• debloat of the build.gradle with "spooky" custom repositories and really a custom format. I mean I mean compare https://gitlab.bixilon.de/bixilon/kotlin-glm/-/blob/master/build.gradle.kts with this one.

Might even be the magic solution to #19

[elect86]

What keeps me away from maven central is:

• a pain in the ass to setup and configure
• additional credentials
• slow to publish
• not as flexible as a personal repo (for example: artifacts are immutable and snapshots aren't easy to pick up deterministically)

Anyway, if you want to embark in this quest, be my guest :)

• lwjgl is a build dependency, especially for the native allocations stuff
• well, the maven publication does bloat the script, imho. But this is easily hidable by creating a custom plugin in buildSrc

Ps: I thought the solution to #19 was enough the how to get it in the readme

[Bixilon]

a pain in the ass to setup and configure

So, yes. There are additional credentials, but that is imho no issue. local publishing is fine or put it up as a ci/cd variable. publishing on gradle is easy (see my build.gradle).

But credentials are super easy to aquire, you just have to open an issue on their jira (sonartype). Fully automatic.

not as flexible as a personal repo (for example: artifacts are immutable and snapshots aren't easy to pick up deterministically)

Yes. There is a snapshot repository. And for the releases: How often are you modifying them? Me: never

slow to publish

You can add the release repository (https://s01.oss.sonatype.org/content/repositories/releases/), that it goes in < 1 minute. Synchronizing it to "real" maven central is done in about 30 minutes.

lwjgl is a build dependency, especially for the native allocations stuff

oh. Looked different, but checked the pom.

Ps: I thought the solution to #19 was enough the how to get it in the readme

Yes, it pretty much is easy but not adding a repository is easier, especially if you project wants to make reproducible builds.

[elect86]

Sorry but I continue to prefer my solution, especially for the time, I can publish in ~10s and it's available literally right away to being fetch as a dependency for consumers

This being said, I do recognise the value of being on maven central, I'm not stopping you at all. If you want, you can go ahead.
The two solutions can be easily exist side by side

[Bixilon]

Okay, I'll register io.github.kotlin_graphics there (hope that works with the hyphen).

No clue how you can publish there then, but my username will have access, I can subscripe to mary and then upload the builds. Hope that works well.

Or self building is better, I can only publish in that namespace.

[elect86]

I'd expect that multiple people might be able to publish, I guess in big organizations is like that, or?

Anyway, in case that's not possible, it's not a big deal, you can publish there

We will find some confy solution on the long run

[Bixilon]

Sure, you can publish. You just need an account on their jira.

https://issues.sonatype.org/secure/Signup!default.jspa

Instructions at https://central.sonatype.org/publish/publish-guide/

To confirm the group, can you create repository https://github.com/kotlin-graphics/OSSRH-92155?

[elect86]

I'll look into it when I get a moment, but I don't see anytime soon unfortunately

Repo create: https://github.com/kotlin-graphics/OSSRH-92155

[Bixilon]

Permission granted (https://issues.sonatype.org/projects/OSSRH/issues/OSSRH-92155), thanks!

You can remove the repository again, I will publish probably tomorrow (went on the Krottenkopf today, quite tired)

If you decide to also publish on maven central, either ask me to add you (requires human interaction I guess) or do a "New Project" request.

[Bixilon]

So, the plan for releasing is....not really present :)

Following possiblities:

• Create another jira account and add it as ci/cd. Problem is, "different" group ids are required (in our namespace). So build.gradle patching is required or custom task like publishMavenCentral that automatically modifies it along with the dependencies?
• Second branch with patched build.gradle (far easier, but then automatisation is kind broken; auto publishing on tags is quite handy)
• Something different?

More questions:

• Signature: Are current builds signed? Should there be a generated key as ci variable (required my maven central)?
• Java docs? All artifacts need (even if empty) java docs. They need to be generated too

And I can't just publish glm, I gotta publish it with all dependencies (kool and unsigned afaik). Maybe publishing other (even more popular) artifacts like dear imgui is a good idea.

Lot of work :)

[elect86]

It should be easy, theoretically it should be enough to just specify the given group in the publication

publishing {
    publications {
        create<MavenPublication>("maven") {
            groupId = "..""
        }
    }
}

• current builds aren't signed, this is another point I never had the time to deal with
• the docs should be there, I'd like to revamp the dokka support (it had a couple of annoying issues in the past)

And I can't just publish glm, I gotta publish it with all dependencies (kool and unsigned afaik). Maybe publishing other (even more popular) artifacts like dear imgui is a good idea.

Really? I'll add you over there as well then

[Bixilon]

Easy, can you release a test build?

[elect86]

What's the best way to do that?

I mean, can I release, test and delete it?

[Bixilon]

I mean, just release a build :)