Hi @Zongle Wang @John Created a channel for discussion of the Shadow Plugin and logistics, if that's fine with you

Hi @Zongle Wang Did you have a chance to follow-up on my comment in https://github.com/johnrengelman/shadow/issues/908?

Yeah, I noticed that. What can I do here?

CCing @Piotr Jagielski @Louis Jacomet who can help with the next steps. I listed the steps on https://github.com/johnrengelman/shadow/issues/908#issuecomment-2202224552, ultimately we still need @John to grant you permissions if we keep the current repo location as a main one

Where should the project repo be transferred to? Do you have any plan?

With Gradliverse being blocked indefinitely, I would keep it on an individual account for now. If you prefer it to be transferred, I suggest GradleUp: https://github.com/gradleup

Yeah, seems we can move to gradleup

Could you add this point to your comment in that issue?

Cc @Martin for GradleUP ^

Hi everyone 👋 Am I right understanding we want to move the repo to the GradleUp GitHub organization but keep current maven coordinates unchanged?

Wait, that won’t work, the maven coordinates are github ones. So if we move the repo, they have to move too

Yes, without Gradliverse or another community location? It will always be a problem. Unfortunately, I do not have any optimistic ETA for having all the necessary approvals, I doubt it will be before September

Could we move the repo But keep the current coordinates for now? If not, maybe we will have to just call @Zongle Wang's fork an official one. It will lead to double community split, but we couldn't do anything else at the moment

FYI @Piotr Jagielski ^

Maybe moving to a new maven coordinate, that's fine

Hey everyone. So I think I would prefer to make a new org in GitHub and move the repo there. And then grant access. It shouldn’t matter that the plugin coordinates don’t match the actual repo location, correct? (For a long time, they weren’t aligned anyway). This would then allow us to step into a new plugin id down the line that’s more generic.

That would be great.

Hi everyone 👋 From GradleUp point of view, we’re ready to accept the project. We’ll just require that: * The maven coordinates are changed to something in the “com.gradleup” namespace (probably “com.gradleup.shadow”?). * The repo is transferred to the GradleUp organization. This will ensure that the project can go on for the many years to come without relying on a single individual. A separate organization works for us too so it’s completely up to you. All solutions work! Let me know if you want to proceed and we can initiate the transfer.

Thanks @Martin! I guess the final call is up to @John to decide on the preference. P.S: Wearing my FOSS Maintainer hat, I have a weak preference towards GradleUP, just to avoid creating more entities that would need maintenance

I’m fine with gradleup. Didn’t realize someone from that group was in the thread.

I’ll do that when I get back from vacation.

Hey everyone. Hectic weak after getting back from vacation. I’ll start buttoning things up to transfer stuff to GradleUp this week (I think i just initiate a transfer on GitHub for that). Few questions for that group - How did you want to do access? How do you want to handle the doc site for it?

@Martin @deepy Can we enable renovate-bot for Shadow repo?

I've been ripping my hair trying to shade a single dependency. I want to publish a JAR that shades a single library, any other dependencies appear like you'd expect in the POM. To achieve this I've created a new configuration, added my dependencies to said configuration and then configured shadow jar to use it. If I then use

publication { from(components["shadow"]) }

then it kind of works, but two things are not ideal: 1. I cannot use

implementation

, instead if I need to use

shadow

. Not a huge deal but still annoying 2. The published JAR uses the

-all

classifier which makes it fail to resolve in some build systems. ◦ I can sort of sort fix this by setting

tasks.shadowJar.archiveClassifier

to an empty string but then it conflicts with the normal

jar

task I've some some projects disable the jar task but that feels a bit hacky. Is there a cannonical way to do this?