Hey all wave Do we have a multiplatform oss project that is

Question

Hey all wave Do we have a multiplatform oss project that is publishing to `mavenCentral` and using the `maven publish` plugin no 3rd parties If yes don t you mind linking pray

Javier · Answer

I had one but `maven publish` is not working very good with mavenCentral because it generates multiple staging repositories we should have two repos one for general artifacts + windows and another for apple artifacts But I was getting 5 or 6 but I think this is not caused by KMP itself So I moved to

Javier · Answer

They are working together in merging both plugin into new one

Javier · Answer

Javier · Answer

I am searching my previous setup with no 3rd plugins

Javier · Answer

but the last one I find is this <https github com JavierSegoviaCordoba Resource blob 0979f2e675b0b0682c57e70d41ad7210984bdf96 buildSrc src main kotlin plugins MavenPublish gradle kts|https github com JavierSegoviaCordoba Resource blob 0979f2e675b0b0682c57e70d41ad 4bdf96 buildSrc src main kotlin plugins MavenPublish gradle kts>

Javier · Answer

but `java library` is not required and I was using dokka in the newer versions

Robert Jaros · Answer

<https github com reduxkotlin redux kotlin> is published to central with `maven publish`

ian.shaun.thomas · Answer

This is a little funky as I wanted JVM to be a dependency of Android so JVM libs depending on this can be used in Android without hassle but it is all maven publish <https github com ToxicBakery Arbor blob master common build gradle L216>

romainbsl · Answer

Hi < gammax> Did you end up with a satisfying solution < Javier> did you use for KMP across platforms linux macos windows My guess is that it would end by creating at least a staging repo by OS when running on CI

gammax · Answer

Not yet I still haven t managed to get back to this But I m planning to send out a PR for < C67HDJZ2N|koin> between today and tomorrow Ideally someone could also chime in if interested in contributing slightly smiling face

Javier · Answer

< romainbsl> at this moment is not possible to avoid the creation of multiple repos with that plugin I did a feature request < mbonnin> library can let you to get this Should be great if it was integrated in some way in the nexus plugin to achieve that

romainbsl · Answer

yep I am considering building everything on each OS put the artifacts in a cache and upload everything once This would be more convenient to us because we are managing multiple libraries on the same repo for < C0BLU9K96|kodein>

Javier · Answer

if you get that working please share the PR here slightly smiling face

mbonnin · Answer

I think what we want is avoid implicitely created staging repos I just made a patch to support this in vespene <https github com martinbonnin vespene commit 8cb910fc82e195424826d9a59576094be16c7704 diff 95efc5ecd7a769d42177ff610c937981dfe38faa1a317a1607e3a2c5a6368c47R23|https github com martinbonnin vespene commit 8cb910fc82e195424826d9a59576094be16c7704 diff 95efc5ecd7a769d42177ff6 aa1a317a1607e3a2c5a6368c47R23>

mbonnin · Answer

I think it s fine to have one repository per OS job and then close them separately in OSS

mbonnin · Answer

Ultimately I think what we really want is a lazy `MavenArtifactRepository url` that only creates the staging repo when publishing and not when configuring the gradle build

Javier · Answer

for me I don t care about how many repositories just closing them via gradle commands But because I haven t a lot of releases of a lot of artifacts repos but I can understand it can be better only one repo for a specific release to avoid mixing different projects etc

romainbsl · Answer

It s fine but as we are managing for now 5 libraries when upgrading Kotlin we would end up with 15 staging repos 5 3 if 1 one as failed it becomes cumbersome to find what are staging repos to drop etc

Javier · Answer

< romainbsl> why do you need 3 OS

Javier · Answer

Is it no enough Windows + macOS

Javier · Answer

or you are using three machines to improve the build time

romainbsl · Answer

we need to build on linux as well at least for some libs as Kodein DB that is compiling leveldb for every possible target

romainbsl · Answer

so we build host only target for windows linux and everything else on MacOS

mbonnin · Answer

< romainbsl> you can put a comment in the OSS staging repository url that ll help identifying the repositories

mbonnin · Answer

Ultimately if <https github community t ability to rerun just a single job in a workflow 17234 5> ends up being implemented having more granular publishing would be easier to manage as you d only re run the one job that failed

romainbsl · Answer

this would be sooo useful But yes explicitly create the staging repo first is my go to It s even better if I can explicitly identify that repo when publishing thx for the tip +1

mbonnin · Answer

< Javier> and I discussed the possibility of creating a staging repo in a first required job Then the question becomes how you d transfer the stagingRepositoryId in subsequent jobs

Javier · Answer

it should be possible in GitHub Actions

Javier · Answer

I don t know about other platforms

Javier · Answer

I will share the reply I get in a few minutes

romainbsl · Answer

With Github Actions you can share cache artifacts For example you can write the repositoryId in a file attach it to your job and then download and read the file in subsequent jobs

mbonnin · Answer

That would work Another solution I was thinking about would be to put the `$GITHUB ACTION` in the staging repository description and then look it up directly from the Sonatype API in subsequent jobs

mbonnin · Answer

For lazy url computing can you upvote <https github com gradle gradle issues 16205>

romainbsl · Answer

yes this could work but what happen if you re run a failed action you may have 2 staging repo with the same `$GITHUB ACTION` in the description

mbonnin · Answer

$GITHUB ACTION changes when you re run I believe

mbonnin · Answer

```The unique identifier id of the action ``` Arg maybe not

romainbsl · Answer

there is a `$JOB ID` I believe

mbonnin · Answer

But `$JOB ID` would be per OS

mbonnin · Answer

Damn Github Actions yellsatsky

romainbsl · Answer

yep sorry gt lt

Javier · Answer

mbonnin · Answer

So much yaml to read and make sense of sweat smile

Javier · Answer

Should be great GitHub Actions get support for Kotlin scripts like YouTrack

Javier · Answer

I think yaml is not a good format for CICD

Javier · Answer

when you have a bit of logic it is very annoying to do simple things

mbonnin · Answer

`maven ` actually supports lazy urls o

mbonnin · Answer

Opening a new staging repo becomes relatively easy <https github com martinbonnin vespene commit deefd80c08c29633a6d86b7e697b4353702f6c98>

louiscad · Answer

If the GitHub action is not resettable maybe another solution is to delete any existing staging repo at the start of the workflow before letting the uploading jobs run

mbonnin · Answer

Why would you do that So that you only have 1 repo

mbonnin · Answer

the implicit one

louiscad · Answer

I d do that so I get one staging repo with all of the artifacts which means easier testing

mbonnin · Answer

Sure but you could also create a repo first and use that repoId in all subsequent jobs

mbonnin · Answer

That will result in one staging repo with all the artifacts

louiscad · Answer

Yep but I was talking about the error case when you need to re run the workflow Or maybe it s a non issue and reuploading just overwrites

mbonnin · Answer

re uploading will create a new one

mbonnin · Answer

Ah I see it now we need a per run id to create a new one

mbonnin · Answer

Yeaaaa

mbonnin · Answer

Also not sure sonatype will like overwriting files thinking face

louiscad · Answer

Another thing we could do is simply generating a staging repo name from the timestamp of the beginning of the workflow

mbonnin · Answer

And then retrieve the ~biggest~ largest one

Javier · Answer

I had problems overwriting files in nexus

Javier · Answer

in snapshot there is no problem

louiscad · Answer

< Javier> What s the difference betweem the two and which one is relevant in the case of uploading to a staging repo for Maven Central

Javier · Answer

snapshot repo doesnt need to be closed or signed

Javier · Answer

You can just upload a version

Javier · Answer

and reupload the same version one week later

Javier · Answer

but I am not sure at 100 because sonatype was having overload when I had that problems

Javier · Answer

so maybe doing a new test is the way to go

mbonnin · Answer

snapshots repo will delete your artifacts aftersometime

louiscad · Answer

gt And then retrieve the ~biggest~ largest one < mbonnin> If you do it all in one workflow you ll not need that since you already have it from the workflow first step

Javier · Answer

< mbonnin> that is the theory I have snapshot there since months

Javier · Answer

even maybe one year or more

louiscad · Answer

That is snapshots not staging repository

Javier · Answer

literally Thu Jun 25 21 01 24 UTC 2020

louiscad · Answer

I personally don t use them snapshots because that makes the builds unreproducible I prefer dev versions I use bintray for that upside down face sweat smile until I can no longer

Javier · Answer

I think using semantic version with nexus is what you want to stable things not only stable releases alphas betas EAPS etc

Javier · Answer

SNAPSHOTS are only for an easy way of testing purpose

louiscad · Answer

I don t want testing to lead to unreproducible builds

louiscad · Answer

Dogfood dog fool