#build-tooling-help

1 messages · Page 27 of 1

fierce anvil
#

The error when running the GitHub workflow:

Execution failed for task ':publishPluginPublicationToHangar'.
> Error uploading version, returned 413: File too large - files have to be less than 15MB total
#

As well as the artifact from the exact GitHub workflow that failed, showing it is 11.9mb:

proper grove
#

i got my own paper fork but Log4j2Plugins.dat isnt being generated and causes issues with logging, how can i fix this?

#

without it, it logs ServerMain ERROR Unrecognized format specifier [stripAnsi]

main mica
proper grove
#

i already got that, the log4jPlugins sourceSet does compile and is in the final jar but not the dat file

lament scarab
#

You need the annotation processor to run

#

And idk about how the merging works anymore, used to rely on the shadow jar plugin for that iirc

proper grove
#

kapt gradle plugin was causing it not to work

lament scarab
#

Because those are from minecraft feature patches applied over the mc tree

#

seperating them would just create complications

woven mirage
#

Hello everyone.
I'm not sure if this is the right channel for this.

Are there any further details on building Paper?
Unfortunately, it seems to fail without any error message and I can't find the error.

I proceed as follows:

    - git clone https://github.com/PaperMC/Paper.git
    - git checkout ver/1.21.4
    - ./gradlew applyPatches
    - ./gradlew createMojmapBundlerJar

The file paper-server-1.21.4-R0.1-SNAPSHOT.jar then appears under paper-server/build/libs.

Unfortunately, I can't start it and get the following error message.

Error: Unable to initialize main class org.bukkit.craftbukkit.Main
Caused by: java.lang.NoClassDefFoundError: joptsimple/OptionException 

Maybe someone has an idea where the error lies or what exactly I need to do differently.

glass warren
#

Is there a reason you're trying to build an old version vs downloading it from the website?

woven mirage
#

The version was just an example.
It doesn't work with main either.
Basically, the idea behind it was to always have the latest version.
If there was a way to automatically download the latest version, I would be happy with that too.
Since the files are located in an R2 bucket, I couldn't see a way to do that right away.

glass warren
woven mirage
#

OK, thank you.
Why keep it simple when you can make it complicated? 😅
I looked for it and couldn't find anything.
Maybe I just overlooked it.

#

Latest is probably one thing, but the latest stable builds should probably cause fewer problems.

slate tapir
#

Does anyone have any example of enabling JVM debugging with run-paper? I'm trying to set up all RunServer tasks to enable debugging, so both runServer and runDevBundleServer have it, but I am missing some unique Gradle knowledge for why it's a final property:

val jbrLauncher: Provider<JavaLauncher> =
    javaToolchains.launcherFor {
      vendor = JvmVendorSpec.JETBRAINS
      languageVersion = java.toolchain.languageVersion
    }

tasks.withType<RunServer> {
  javaLauncher = jbrLauncher
  jvmArgs("-XX:+AllowEnhancedClassRedefinition")

  debugOptions {
    debug = true
    suspend = false
    server = true
    port = 5005
    host = "*"
  }
}

This fails to actually run the server, since the enabled property behind the debug getter/setter is apparently final

static urchin
#

don't think you need to do anything but just, press the intellij debug run button

slate tapir
#

The debugOptions aren't in docs to be fair, another user said that's the newer way to do the hotswap setup in the pins

static urchin
#

pretty sure most of these options are only needed if you are not using runPaper

final jewel
#

in reality, you only need debug = true in there, I explicitly configure all of the properties because I change them sometimes

slate tapir
#

debug = true bugs out for debug run configurations in IJ, or it does for me anyway

#

It's a final property

static urchin
#

Ye idk, I literally plug nothing in there

final jewel
#

if you run it via intellij, just using the debug button is enough, I mention that in the message too

final jewel
#

it is probably getting confused between a function call and actually setting a property

slate tapir
#

There is no setters/getters with the kotlin DSL, it just exposes it as a property

slate tapir
#

Yes, there are, but kotlin does the same thing it does for every get/set method and turns it into property access

final jewel
#

though I guess it is probably better to just do enbled = true instead

#

not sure why I was doing debug = true considering debugOptions has set/getEnabled

#

that's what the javadoc recommends too

slate tapir
#

Yeah, that's true - not my issue I think though. I wonder if it's because I'm trying to configure the tasks after creation

final jewel
fierce anvil
#

Is there a proper channel to request support with Hangar? This seems to be an issue with Hangar itself, but I was directed here.

fierce anvil
#

Thank you, looks like I didn't have the channel selected.

brisk belfry
#

any1 of the gradle pros know what could be the issue here?

Could not initialize class org.gradle.toolchains.foojay.DistributionsKt

Exception java.lang.NoSuchFieldError: Class org.gradle.jvm.toolchain.JvmVendorSpec does not have member field 'org.gradle.jvm.toolchain.JvmVendorSpec IBM_SEMERU' [in thread "Daemon worker Thread 9"]

novel knoll
#

you probably want to update the foojay resolver plugin to the version that supports gradle 9 if you're going to run gradle 9

brisk belfry
#

thank you

thorn oxide
#

why is it git ignored? how do i do minecraft patches then

fading vapor
thorn oxide
#

what do i modify to make a minecraft patch

#

i believe it was different in 1.21.8

#

i just modified fork-server/src/minecraft

main mica
thorn oxide
#

on 1.21.8 it was fine

#

now im updating to 1.21.11 and its like this

#

this is on 1.21.8

#

on 1.21.11

static urchin
#

add it as a VSC dir in IJ

thorn oxide
#

how

static urchin
#

Version Control > Directory Mappings

thorn oxide
#

and where is version control

#

sorry

#

Found it

#

Thanks

#

now its stuck in git am for no reason

turbid moon
#

Hey, I made a PR to update the paperweight-examples v2-fork example to 1.21.11 (PR link: #34) and for some reason running either gradle test or gradle runDevServer reports exceptions in the net.minecraft.core.registries.BuiltInRegistries class.

I did not modify any patches, only simply updated them to apply correctly for the current Paper reference, so I am very uncertain where the error comes from. If anyone could shed some light onto that, that'd be great (turns towards jmp)

Gradle scan of ./gradlew test: https://scans.gradle.com/s/fywnkj3vzqyuu.

tepid sigil
#

what did you do to gradle.properties

turbid moon
# tepid sigil what did you do to gradle.properties
apiVersion=1.21.11-R0.1-SNAPSHOT
mcVersion=1.21.11
paperRef=3ebc5b3320924e9122903dfd1f11abcf897300e6

I assumed that version needed changing to apiVersion because of a previous compilation error around that property missing

#
> Task :fork-api:generateApiVersioningFile FAILED

[Incubating] Problems report is available at: file:///home/strokk/dev/java/temp/paperweight-examples/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':fork-api:generateApiVersioningFile' (type 'Build_gradle.GenerateApiVersioningFile').
  - Type 'Build_gradle.GenerateApiVersioningFile' property 'apiVersion' doesn't have a configured value.
    
    Reason: This property isn't marked as optional and no value has been configured.
    
    Possible solutions:
      1. Assign a value to 'apiVersion'.
      2. Mark property 'apiVersion' as optional.
    
    For more information, please refer to https://docs.gradle.org/9.2.1/userguide/validation_problems.html#value_not_set in the Gradle documentation.

* Try:
> Assign a value to 'apiVersion'
> Mark property 'apiVersion' as optional
> Run with --scan to generate a Build Scan (powered by Develocity).
#

Keeping the version property alongside the renamed apiVersion (meaning version, apiVersion, and mcVersion are set) does not help the original issue

tepid sigil
#

that's very scary but you can wait jmp or ask lynx nicely cause there's multiple branch to update

#

there's no renamed property apiVersion is a brand new property

novel knoll
#

yeah that's it, just tested locally

turbid moon
#

So keep version with the -R0.1-SNAPSHOT suffix but also add apiVersion, which is the same here as mcVersion

#

Weird that these need to be set separately, aren't they always gonna be the same anyways?

#

(and thanks lulu as well, I just saw you said the same thing with the apiVersion property)

turbid moon
sudden verge
#

Can anyone tell/help me how to properly update my server software from minecraft version 1.21.8 to 1.21.11? I tried changing the mcversion and the paper/purpur ref to the latest. and I kept getting a lot of patches rejects errors..
https://github.com/Gr1mly4Memes/blaze
Any tips would be appreciated!

GitHub

Purpur fork . Contribute to Gr1mly4Memes/blaze development by creating an account on GitHub.

main mica
#

You need to fix the conflicts in your patches

#

the log should tell you which patches failed, and paperweight will also create a rejected folder with the changes that failed to apply

turbid moon
#

Basically just manually re-apply the failed chunks by hands

#

Or you could try fuzzy applying, I heard that can help in some cases (there are extra tasks for that)

main mica
#

fuzzy is a bit 50/50, it sometimes also drops changes silently lol

sudden verge
main mica
#

Just like you go about editing every other patch

#

build files use the single file patches tasks, there is no fixup task for them tho

sudden verge
main mica
#

yep. Not sure which of those two you need to use for a fork-of-a-fork, but that is the correct task generally

sudden verge
#

Purpur is a fork of a fork of a fork. Many forks

sudden verge
lament scarab
#

I mean, the rejected patches are hunks which failed to apply

#

you will need to manually reapply them

#

(also, make sure that paperweight is updated)

sudden verge
echo kilnBOT
sudden verge
#

but I keep seeing paperweight 18 when applying patches

lament scarab
#

I mean, if you keep seeing 18 then you'd want to check that it's not using 18 due to being set that somewhere

#

.19 changes the default diffpatch mode to allow line numbers to check in patches, (but, you're still going to likely have to deal with some rejections manually)

sudden verge
lament scarab
#

I can't provide support for that

sudden verge
lament scarab
#

I mean, on the nature of it being 4am, not really; but, I can't really see what you're looking at anyways, if it's saying that it's using .18 you'd want to work out why, otherwise, hunks failing on your own patches is likely just because stuff changed, go reapply those changes manually

torn sonnet
sudden verge
#

primarly this issue is haunting me

torn sonnet
#

Your last message in their server is in NOVEMBER

#

maybe you're forgetting to press send

sudden verge
#

I remember sending my message.

#

unless im a schizo

torn sonnet
lament scarab
#

setupMacheSources failing would generally be down to a java version mismatch

#

(outside of some decompiler version mismatch)

sudden verge
lament scarab
#

it's sensitive to the JDK version

#

not just the targeted source version

sudden verge
lament scarab
#

21

sudden verge
#

im using 21. maybe it like temerin?

lament scarab
#

what JDK are you using to run gradle with?

rapid fractal
#

Btw this is what no-ping means @sudden verge disable that @

sudden verge
torn sonnet
#

cat go to bed

#

chicken, post in teh purpur server lol

sudden verge
haughty plover
#
  1. clone PaperMC/Paper-archive ver/1.20.4
  2. ./gradlew applyPatches
  3. boom!
Applying: Build system changes
error: Your local changes to the following files would be overwritten by merge:
    src/main/RANDOM_FILES.java
Please commit your changes or stash them before you merge.
Aborting
error: Failed to merge in the changes.
- error: Your local changes to the following files would be overwritten by merge:

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
- error: Failed to merge in the changes.

It has about a 5% chance of success.
?????

#

how to fix it?

lament scarab
#

You would need to work out why it thinks those files are modified

#

I would also generally make sure that stuff is updated, git, etc

#

But, those versions are unsupported so, generally, good luck

haughty plover
#

omg....

thorn oxide
#

how do i create a patch for build.gradle.kts

#

rebuildAllServerPatches doesnt do this

fading vapor
thorn oxide
#

thats not the correct way

fading vapor
#

okay

thorn oxide
#

iirc one of the rebuild commands does this

lucid mulch
#

but i dont blame him, i also used the output of diff for modifying those patches at first kekw

#

until jmp corrected me here when i advised that to someone

lucid mulch
#

it will be in the next release

echo kilnBOT
lucid mulch
#

your error points to userdev possibly being outdated

#

ensure you go through all the steps here

deep echo
#

I've updated the userdev version to the one mentioned. I didn’t opt for it before because it was listed as beta. It seems to be working in the new project, so I’ll try it in the previous one.

#

Thanks, it looks like updating Gradle and UserDev was indeed necessary. It’s working now in both projects.

sudden verge
#

When making patches for my Paper fork, the patches just "stack" on each other. Like I make one patch, it just combines and renames the other, I cant go past 8 patches without any of them get renamed, also it doesn't show the correct person who made the patch. It just shows papers contributors/devs, not to mention showing the wrong date. For an example I made a patch to fix Fix MC-305453, but got replaced with my other one: Small-optimization-to-LinearPalette.
The link to show what I mean:
https://github.com/Gr1mly4Memes/forge/commit/874a47d05cd128fb8a60cba52d6157e1afd80864

lament scarab
#

I mean, it looks like you appended the changes rather than making a seperate commit

#

(This is all generally just git stuff with some helper stuff around it, we don't touch the author of feature patches, etc)

sudden verge
#

I do commit amend, is that not the right thing to do? I do git add . and the amend commit

lament scarab
#

No, amend amends the last commit

#

that's why your changes are on the last patch file rather than in a seperate one

sudden verge
#

ooh, okay, then what should I do instead?

lament scarab
#

you just commit normally

sudden verge
#

ok, thanks. Now I just have to redo all the patches

sudden verge
#

How do I remove these annoying warnings when building a paperclip jar?

lament scarab
#

Outside of disabling warnings in general you can’t

harsh ore
#

which task should we use to build userdev plugins in 1.21.11? I remember reading somewhere that reobfjar shouldn't be used due to minecraft being unobfuscated

lament scarab
#

You would just use the standard build task

lilac widget
# thorn oxide iirc one of the rebuild commands does this

Which one is this? I've tried running all of them

(So for clarification:

  • I ran applyPatches and it generated a build.gradle.kts in fork-server
  • I then modified build.gradle.kts
  • I then tried running every :fork-server:rebuild...Patches task but none of them modify the build.gradle.kts.patch
    )
lilac widget
#

Which one is that?

turbid moon
#

rebuildPaperSingleFilePatches

lucid mulch
#

read what ./gradlew tasks says

turbid moon
#

I believe

lucid mulch
turbid moon
#

Based on the fact that they are using :fork-server, I think so

lucid mulch
#

thats why its good to advise to read what the tasks output actually says

turbid moon
lucid mulch
turbid moon
rapid fractal
#

People who can’t be bother to read the doc probably shouldn’t be making forks

lilac widget
#

So I'd assume it's one of these from gradlew tasks:
rebuildPaperServerFilePatches - Rebuilds paperServer file patches
rebuildServerFilePatches - Rebuilds paperServer file patches
But both of them do not create/modify fork-server/build.gradle.kts.patch

(I can't find any docs for this specifically)

lament scarab
#

There is a task specific for single file patches

lilac widget
#

Do I need to stage build.gradle.kts somewhere maybe? I felt it should be in .gitignore

lucid mulch
lucid mulch
lilac widget
#

Ah it's rebuildPaperSingleFilePatches - Rebuilds all paper single-file patches

lucid mulch
#

yes

lilac widget
#

Thank you! It was in the top module, I was looking in each specific module since that's where every other patching task lives

turbid moon
#

I love that I spoon-fed the task

#

But it seems to not have helped copium

lilac widget
#

It is definitely right there but it's not easy to find a needle in that haystack 😅

#

There's so many almost similarly named tasks within the module itself that I didn't think to check the top-level module tasks, which has all the tasks from the submodules so it just looks like 2x the tasks, it's really hard to notice the few extras

#

I didn't know it would have the word "single" in the name, "rebuildPaperServerFilePatches" is like as close as you can get xD

turbid moon
#

I mean, generally you typically already know if you want apply, rebuild, fixup, or whatever tasks

#

And there aren't so many server-related rebuild tasks

lilac widget
#

True

lilac widget
#

So I see you have a shiny Docs Team badge, that's cool :D Are there any docs specifically for creating a fork apart from the template existing?

torn sonnet
#

Fork stuff is pretty documented on the example repo(s)

lilac widget
#

Not that I mind, but just trying to make sure I don't miss any place to reference

grand niche
#

the code is basically all the documentation

#

afaik it intentionally isn't documented because there's a general expectation that you're able to read and understand the code if you're interested in doing a fork

#

paper's contributing file describes how to deal with patches and such, the fork tooling shares much of the same concepts

#

if you're stuck, you could ask here or in one of the topical channels and someone will probably help you with it

turbid moon
brisk belfry
#

I mean I had the same impression.

lament scarab
#

I mean, it's not intentionally undocumented, it's just there comes a level of expectations around what people using the tooling is experienced with; We can provide some onboarding and such to the tooling, but, we can't get you competent with git

turbid moon
#

Yeah my whole idea was to just lead people to the tooling and the concept, maybe lead through the creation of one patch as a general reference, because I know from my own experience that even checking the tasks output, if you are unfamilliar with how the patcher itself works, you might not understand it at first anyways

lilac widget
#

I'm a bit stuck again 😅

So for a fresh fork with no patches, I've only made one change: added a different logo called logo.png in fork-server/src/minecraft/resources

Which task could I use to include this change in a patch? I haven't been able to get it done.
fixupPaperServerFilePatches gives the same error as when there are no changes
fixupMinecraftResourcePatches does add the file to the fork File Patches commit, but when I run rebuildAllServerPatches, nothing happens

✅ EDIT: got it, since it's a part of Paper, I've changed it in paper-server and now rebuildAllServerPatches picks it up!

junior pelican
#

I'm trying to update my fork 1.21.8 to 1.21.11, but I'm encountering some invalid object errors.

I found [this](#build-tooling-help message) and set oldPaperCommit, but now when I apply the patch, I get this error
paper.libs.org.eclipse.jgit.api.errors.InvalidRemoteException: Invalid remote: old

I've already add remote repo old in the root git and set it to https://github.com/PaperMC/Paper.git. Did I do something wrong?

brisk belfry
#

I mean 1.21.8 is already new paper

#

So you just want to use paperRef or whatever it’s called in settings.gradle

#

oldPaperCommit is for when you are trying to update a pre-hardfork paper fork to post hardfork

junior pelican
#

Oh, my idea is that it can be used to improve the success rate of 3-way merge.

brisk belfry
#

ok maybe I am wrong, someone with more knowledge might be able to give more insight.

But yeah I think it should work if you set paperRef to the new commit and also change the respective properties in gradle.properties

brisk belfry
junior pelican
#

Of course, I have updated paperRef to the latest commit, but most patches are showing invalid object , so I'm looking for a more efficient method than manually merging them all.

Anyway, thanks for your reply!

lucid mulch
#

it isnt exposed to forks

#

so it will cause failures

junior pelican
#

but why did jmp mention this when answering paper fork question? I just wanted to confirm, not to accuse.

lament scarab
#

I mean, it is applicable to forks afaik

#

the old repo isn't for the parent project, it's for the patched tree, iirc; Because that's where the merges occur, and where you'd need the old repo to be available for the 3way to occur

junior pelican
#

Let me see where I should add the old repo. Thank you!

sudden verge
lament scarab
#

I mean, sure

sudden verge
lament scarab
#

I mean, I've never touched linear, but the region system generally doesn't care so long as whatever RegionFile class implements the methods and returns the data it expects

sudden verge
final jewel
sudden verge
final jewel
#

it also seems that they ported the old linear patches

#

would recommend starting from scratch to implement linear v2 instead

sudden verge
#

ok gotcha, is there a refrence I can look?

final jewel
#

well, reference would be the old linear implementation in LinearPaper or that fork you linked above 😛

final jewel
#

they seem to have a document detailing both v2 and v1 details, so you can probably work it off that

sudden verge
#

ok, im just going to have a fun day implementing this

final jewel
#

yeah, it does soon like quite the pain in the ass to implement given the only reference implementation is on python

sudden verge
#

yeah

pliant remnant
#

sr this is my first time

final jewel
pliant remnant
#

yes

#

how i can do it? with paper-plugin.yml?

brave widgetBOT
final jewel
#

though I would recommend just using the normal plugin.yml given you aren't using any of the paper plugin features

real sail
turbid moon
#

Your Gradle is outdated, update your Gradle

echo kilnBOT
chilly kayak
#

question about hangar publish gradlew plugin
if I want to upload two jar can I just publications.register another one ?
-# detail: one of my user has an heavy firewall (likely) allowing only he's proxy.
-# so I have 2 jar: one that download libraries and one that shadow them and plan to make an "offline jar release" channel in parallel of generic release

smoky violet
#

that sounds reasonable, try it

chilly kayak
#

seems to work thanks !
"just" had to use the publish all instead of publish plugin gradlew task cerbyLUL

tough pike
#

Is there a way to have subprojects inherit the dev bundle so that I don't have multiple copies of Paper source showing up in my IDE?

#

Can't even apply the API version I want for all of them inside of subprojects because of how userdev works, can't apply it in my main file or it requires that it be set there

import org.jetbrains.kotlin.gradle.dsl.JvmTarget
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    idea
    kotlin("jvm")
    kotlin("plugin.serialization")
    id("io.papermc.paperweight.userdev") apply(false)
    id("xyz.jpenilla.run-paper")
}

group = "me.elephant1214.nexus"
version = "1.0.0-SNAPSHOT"

repositories {
    maven("https://jitpack.io")
    mavenCentral()
}

subprojects {
    apply(plugin = "org.gradle.idea")
    apply(plugin = "org.jetbrains.kotlin.jvm")
    apply(plugin = "org.jetbrains.kotlin.plugin.serialization")
    apply(plugin = "io.papermc.paperweight.userdev")
    apply(plugin = "xyz.jpenilla.run-paper")
    
    repositories {
        maven("https://jitpack.io")
        mavenCentral()
    }
    
    dependencies {
        implementation(rootProject.libs.bundles.kotlin)
        implementation(rootProject.libs.bundles.exposed)
        implementation(rootProject.libs.bundles.cloud)
    }
//...
}
tough pike
#

I want to split my plugin into multiple plugins as modules, but maybe it isn't needed

turbid moon
polar edge
lament scarab
#

99% of the time I see that error is down to people breaking their build by making the shadowJar output blindly replace the jar task output

polar edge
#
tasks.shadowJar {
    archiveFileName.set("ZCAPI.jar")
}
```So this?
#
plugins {
    java
    id("com.gradleup.shadow") version "9.3.1"
}

group = "lt.itsvaidas"
version = "1.0"

repositories {
    maven("https://repo.opencollab.dev/main/")
    maven("https://repo.extendedclip.com/content/repositories/placeholderapi/")
    maven("https://jitpack.io")
    maven("https://maven.maxhenkel.de/repository/public")
}

dependencies {
    compileOnly("com.github.MilkBowl:VaultAPI:1.7.1")
    compileOnly("org.geysermc.floodgate:api:2.2.2-SNAPSHOT")
    compileOnly("me.clip:placeholderapi:2.11.5")
    compileOnly(project(":ZCWebsiteLinkAPI"))
    compileOnly("de.maxhenkel.voicechat:voicechat-api:2.5.36")
    implementation("com.zaxxer:HikariCP:7.0.2")
}

tasks.shadowJar {
    archiveFileName.set("ZCAPI.jar")
}

tasks.build {
    dependsOn(tasks.shadowJar)
}

This is the whole zcapi projects build kts

lament scarab
#

Yes, that would break it

polar edge
#

And how to correctly replace the file?

lament scarab
#

You don't

#

replacing the file breaks the build

#

if you want to rename stuff you would need to override the jar tasks output

polar edge
#

I want the final jar to have that name

#

How could I do it?

lament scarab
#

Then change the name of the jar task

polar edge
#
tasks.shadowJar {
    archiveFileName.set("ZCAPI.jar")
}

tasks.jar {
    archiveFileName.set("ZCAPI.tmp.jar")
}
#

Like this?

lament scarab
#

sure, I guess

lucid mulch
#

you can also disable the jar task @polar edge, that should fix it too afaik

#

enabled = false or sum

novel knoll
#

that is not a proper fix really

#

i personally prefer modifying the individual components of the archive (classifier etc) rather than the final file name, but those really should to be different, as disabling the jar task doesn't have the same effect on all the whatevers gradle tracks about the tasks

turbid moon
#

I typically set the archive classifier for the jar task to "noshade" and the archive classifier of the shadowJar task to null for no suffix

#

I am not sure if that causes issues, but I personally haven't run into any yet

novel knoll
#

that's fine, that's what I do too

lucid mulch
# novel knoll that is not a proper fix really

it is a fix tho, the best way is to not use the same archive names for both files sure or using classifiers but if he really doesn’t need the jar’s task output he can just disable it altogether (like you said)

#

don’t see the point in having a useless jar file being produced and laying around

timid shadow
#

How to create per-file-patches? (paper-server/patches/sourse/...)
I read Contributing.md, but it only showed how to create large patch commits. ( 001-commit.patch )
How can I make a per-file-patch commit?

main mica
pallid elbow
#

Anyone, uh, tried using AI to help them upgrade their patches to update their fork to latest mc version?

novel knoll
#

i can't wait for AI generated commit and file hashes

pallid elbow
pallid elbow
lucid mulch
#

it automatically downloads the jdk and builds using it so you won’t have issues

turbid moon
#

Generally it doesn't matter, you can build it with Java 25 as well, but you'd need to set the toolchain version then too

#

Since that's, as said by our Cyrillic friend, is what actually determines the version used for building

#

It's just important for me (and a few other people) to have updated Gradle as Gradle itself won't run with 25 if on an older version

pallid elbow
#

Things seem to explode when trying to build against 25 so i'll avoid that for now

lilac widget
#

When I checked earlier the new spark-paper hadn't been published to the Paper repository yet so you need to build and publish to local

pallid elbow
static urchin
pallid elbow
#

well i'm also confused as to why this doesn't seem to be in git

#

That's what feels like it's making my PR weird, as it should be a single commit in my past experience

lament scarab
#

The Minecraft source folder doesn’t exist in the repo, it legally can’t, that stays local and is what the patch system generates

#

Feature patches apply over the top of file patches, if you modify an earlier patch it can impact the diff of later patches, in this case, the diff in EAR changes because you changed a line which was in the context of a hunk in there

pallid elbow
#

So how is one supposed to generate a patch to do that change then?

#

However I did it for that PR was mostly on accident

lament scarab
#

Do what?

#

If you modify the Minecraft tree then that gets rebased into the single file patch commit in there, there is a gradle task to fixup that commit

#

Basically, the file tree has changed a bit, but, the git stuff all mostly stays the same, there is now just also a commit in there specially for single file patches

pallid elbow
# lament scarab Do what?

I'm modifying net.minecraft.world.entity.Entity, so I guess the question is which gradle task grabs that change and patches it, since it's not in git and thus has no add commit, rebuild, applyPatches thing

lament scarab
#

It is in git

#

There is a git repo in the Minecraft/java folder

#

There is also a gradle task with fixup in the name

pallid elbow
#

I think IntelliJ must've been just having a crisis then (see above screenshot from earlier), cause it shows up now

pallid elbow
#

(fork question) how does one rebase and get the fork-server/minecraft-patches? rebasing in paper-server only shows the patches in paper-patches

turbid moon
pallid elbow
#

edit a patch in fork-server/minecraft-patches

#

rebase -i base in paper-server only shows patches in the paper-patches folder

lucid mulch
#

fork-server/src/minecraft/java

pallid elbow
#

oh yeah, thanks

pliant remnant
#

How can I adjust the indentation distance of the tree folder in intellijd? It takes up too much space on my screen

proud maple
#

you'd probably want to enable the option called "use smaller indents" when you go to the tree view settings

pallid elbow
#

@static urchin with this, apologies since i'm new to any PRs since the hard fork: https://github.com/PaperMC/Paper/pull/13552/changes#diff-8dfc3884f0d1af360329ee2daaa8a501e2358cc36b54ba04c67fb555b1b5b8d6

implemented on source file level
I don't really understand feature patch vs not in this regard. I just made the changes and the feature patch is what committing + rebuildPatches made.

(for my various PRs), i also don't therefore get when the // Paper stuff isn't needed. At least in the org.bukkit.entity.Player, I still see paper comments all over that file (unless that's just due to a lack of cleanup?)

static urchin
#

Yea they are leftovers

#

For feature vs source patches

#

Paper basically is a fork within itself if that makes sense.

pallid elbow
#

so just no new comments on -api?

static urchin
#

No where outside Mojang code

#

But yea so. Feature vs source patches. We want paper to compile with just source patches applied

#

Then on top of that go feature patches that might need longer during the update process

pallid elbow
turbid moon
#

Files patches are basically one big feature patch by themselves, just split up happy

static urchin
#

E.g moonrise

static urchin
#

Basically, if it's java code checked into our repo, no need to comment. If it ends up in a patch, comment

#

And then yea, your changes for that definitely would want to be in source file patches

pallid elbow
#

ok comments make sense, but this doesn't to me still:

This should be implemented on source file level and then fixed up in the improve keepalive patch.

#

was i meant to... divine the existence of the keepalive patch? (i vaguely remember it but yeah)

static urchin
#

I mean, you would have gotten slapped with it if you tried to edit the per file patches

#

No need to divine anything

#

As said, the idea is that paper compiles and runs with just the per file patches applied

#

You are adding API and CB changes

#

Paper will not compile unless those fields exist, so they need to go into the per file patches

#

Doing so will then break the keep alive patch because it massively rewrites that bit

#

At which point, you'll need to adapt that patch too make sure your new addition still runs

#

As said, we are kinda a fork within ourselves. You change source/per file patches -> all the feature patches that touch that changed area need an "upstream update" (not really but, you get the idea)

pallid elbow
static urchin
#

Which is wrong

#

You should have had that intention

#

Which is what I pointed out in the review

pallid elbow
#

So my workflow should've been to find an existing patch that relatively impacted that area of change?

static urchin
#

No

pallid elbow
#

aka see if there's a --

static urchin
#

Fixup your changes into the per file patches

pallid elbow
#

I do not understand that statement

static urchin
#

Read our contribution guidelines then

#

They explain that I believe

pallid elbow
#

They do sorta, it wasn't clear to me whether between steps 1 and 2 there was meant to be a git commit

#

i'm used to the old workflow atm:

  • make change
  • commit with name (of would-be patch)
  • rebuild, apply, boom there's your patch
static urchin
#

You don't have to no

#

The gradle bit automatically does the commit and fixup

#

As said, it will error in your case

pallid elbow
#

ok let me try it all over again then

static urchin
#

Because a feature patch after that will no longer apply

pallid elbow
turbid moon
#

Also by what lynx means is to just make a per file patch out of it

turbid moon
#

@pallid elbow to be fair, fixing this up into file patches was a bit harder since you are modifying content from another feature patch, whilst we still do kinda want stuff to compile without feature patches as well. Here, have a diff you can apply to fix that up lmao: https://pastes.dev/O7FJGdjhGh

#

Absolute spoonfeed, but I think it's fair in this case

pallid elbow
#

which i am doing now, although admittedly i am thrown for this one

turbid moon
#

I can guarantee you that you will have a hard time here

pallid elbow
#

typically i'm pulling from the right on this but following that strat ended up with a changelist that removed the keepalive patch which isn't right

turbid moon
#

Don't wanna discourage you from trying it yourself though, since doing that is the best way to learn

pallid elbow
#

I mean i've been doing a fork for years so it's not my first paper fixup

turbid moon
#

Fyi though the way I'd suggest doing it is to not apply any patches at all (rename the feature patches dir) and do your change that way first and then try to apply the feature patches over that, resolving any conflicts

pallid elbow
#

I'm at the stage of having only made changes, and am at fixup

#
[main 1853505] fixup! paper File Patches
 1 file changed, 3 insertions(+)
Auto-merging net/minecraft/server/network/ServerCommonPacketListenerImpl.java
CONFLICT (content): Merge conflict in net/minecraft/server/network/ServerCommonPacketListenerImpl.java
error: could not apply 1853505... fixup! paper File Patches
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply 1853505... # fixup! paper File Patches

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':paper-server:fixupSourcePatches'.
> io.papermc.paperweight.PaperweightException: Command finished with 1 exit code: git -c commit.gpgsign=false -c core.safecrlf=false -c sequence.editor=: rebase -i --autosquash upstream/main```
pallid elbow
#

I get a lot of noise in changed files when switching branches between my PRs. What's the right order of operations for clean? applyPatches?

lament scarab
#

if you switch branches you would need to apply patches in order to make that branches patches, etc, be the actual set of stuff you're changing

lucid mulch
#

I have an idea related to userdev that i would like to discuss here before pr'ing.
Namely, i'm developing a custom gradle plugin that interops with userdev and applies access transformers to the server jar contained in the dev bundle. However for me to be able to achieve that cleanly, I needed to implement hooks in my fork of paperweight that allow users (and therefore plugins) to disable injection of the server jar into the configurations produced by userdev, allowing me to intercept that jar in the plugin, modify it, and then finally add it myself to the userdev configurations.
So my question becomes, is there a chance that such a PR exposing an option in the userdev ext to disable the jar injection will be accepted (that perhaps could be used by others wanting to create similar projects too)? I get that this is a bit of a very specific usecase, given the fact that the jar is the whole point of having a dev bundle but i would want to provide compatibility with consumers using paperweight too and not require them to switch over as those userdev impls in both my plugin and pw don't differ that much except for these hooks.

pallid elbow
#

ah yeah this is one of those IJ problems where it thinks i'm on master but i'm actually on despawn2

#

anybody ever figured this one out?

turbid moon
#

I just use the command line

#

It makes this so much nicer imho

smoky violet
lucid mulch
turbid moon
#

Oh yeah, jmp, whilst I've got you here, since we've talked about the default MCDev template not being all that good, I've made a PR which addresses that. Basically it adds this fun little advanced options block to the creator, which allows you to select a bunch of things people tend to typically include in their plugins. It now also ensures to always use the latest Gradle version, only uses the Kotlin DSL, and also adds a sane gradle.properties file setting the following values: ```properties
group=yay.namespace
version=0.0.1
org.gradle.configuration-cache=true
org.gradle.parallel=true
org.gradle.caching=true

For the specific options I have selected in the screenshot, the following build file gets generated: <https://pastes.dev/FVsS6yS8oZ>. I've been wanting to ask you if you could take a quick peek over it and tell me if there's anything missing, obsolete, or not well generated, since this'd be a great opportunity to change things before it gets merged.
smoky violet
turbid moon
#

modal? Like the project creator?

smoky violet
#

yeah

#

i.e. not just the 'advanced options'

turbid moon
#

Gimme a sec, not sure if I can get this on one screenshot

smoky violet
#

I was just thinking, plugin bootstrap & version catalog could probably go somewhere else, and then you could call the section 'Gradle Plugins' or smth with headers for the option groups of each plugin

turbid moon
smoky violet
#

as is it's a bit overwhelming with the amount of options and not much hierarchy in the advanced section

turbid moon
smoky violet
#

even just a spacer between each plugin's "section" could help I think

turbid moon
#

But it also kinda toggles automatically, like if you tick gremlin, it doesn't allow you to select the loader or shadow jar, as both are forced

#

I could maybe move the catalog directly below build system and the bootstrap/loader below the paper manifest option

#

Ohh I know now why I moved the loader down

#

Because it depends on the gremlin option, since it disables itself depending on if you use that plugin

smoky violet
#

like, maybe a gray line or whatever where those green markers are?

turbid moon
#

I'll look if I can get something like that in, I am not super familiar with the templates here

smoky violet
turbid moon
#

Hm I don't think there are any separators in this template system

smoky violet
#

hm, couldmaybe just bold the "Use the ... Gradle plugin" text (also make them all "Use" or all "Include" PepeLa)

#

that would also give it visual hierarchy

turbid moon
#

I sm not even sure if the IJ project creator dialog supports them at all, though I don't see why not, since it's just the JDialog stuff or something

#

Ohhh maybe I could inline it

#

I just saw that some of the modded stuff has that

smoky violet
#

also I would put gremlin at the bottom, it's the least commonly used

turbid moon
lament scarab
#

I’d probably rename that tab to extras, I don’t think most of the stuff there is too advanced

#

Run paper is basically a free value add

turbid moon
dreamy jungle
# turbid moon hmmm

how do you find gradle plugins in the minecraft development plugin? because it doesnt exist.

turbid moon
#

Maybe soon™

dreamy jungle
#

a

#

i have been trying to get paperweight working for the past 3 hours and i give up

#

and the template online doesnt build.

turbid moon
echo kilnBOT
turbid moon
#

For the Gradle update step you might want to first comment out the userdev plugin so that your Gradle commands run

dreamy jungle
#

o

#

omg i just needed to remove mavenCentral() from settings.gradle.kts

dreamy jungle
#

anyways uh

#

i bet it doesnt have documentation to use NMS correct?

turbid moon
#

It's hard to document ever-changing code

dreamy jungle
#

figured

#

alright thanks

half stone
#

Hi, I currently use a fork of paper, and am wondering how I could import patches from a seperate fork of paper, or more info on how the patch system works
would i need to turn the parches back into code then copy paste those changes over and make new patches? if so how do i do this?

turbid moon
#

The simplest way would be to even just copy the patch file and add it into your patches directory (numbering it accordingly so it fits with the other patches you have)

#

But depending on what changes they are doing, for what commit of Paper the changes were made, and what changes you've done already, the patch apply might fail and you would have to fix the conflicts (also in that folder)\

turbid moon
#

Anything I've missed in the build scripts themselves?

brisk belfry
#

Why Java library?

turbid moon
#

The paperweight-test-plugin also uses java-library. For a single module plugin there is no real difference I suppose, but you oftentimes do come across uses where java-library is better (like if you want your plugin to be depended upon by another plugin and wish to expose some transitive dependencies/don't want to expose internal dependencies)

final jewel
#

also, do you support gremlin on the spigot template too? Or are those just if using paper

brisk belfry
#

-# sorry lets not get offtopic in here

turbid moon
final jewel
turbid moon
pallid elbow
#

Something change about debug-running runServer? It used to work in IJ back in 1.21.8

#

seems to just hang here but not actually run the server

shrewd crestBOT
lucid mulch
#

hey i opened a PR that exposes a configuration option to fail on inapplicable ATs just like lynxplay described in #344 but i'm not too sure about some defaults so i went ahead and left a couple of reviews for maintainers to look at when they have time, i'd appreciate if i could get some quick responses as i won't have too much free time to make adjustments starting at the end of next week

#

the main question is if we should error by default, i opted to make it retain current behaviour aka not fail for now to avoid "breaking changes" but i'd appreciate some feedback as i myself see the benefits of making it fail by default

sudden verge
#

How to update existing patches with newer code?
For an example: I edit some minecraft or paper code, then made a patch. Realized I made a mistake and I need to change it.
Do I just edit the code and then rebuild the patches again?

lucid mulch
sudden verge
lucid mulch
#

and it is a feature then just rebase and amend the commit in the src/minecraft/java or some other git repo that youre modifying and then rebuild

lucid mulch
#

paper’s contributing md explains this in detail; it might prove useful for other questions you might have in the future too

lucid mulch
#

both of these pr's conflict with eachother, in the sense that one needs to be modified to account for the other's changes based on what order they get merged (if they even get merged), but i already have taken care of that in my local fork as per the comment

hardy tendon
#

I'm trying to update our semi-abandoned fork from 1.21.10 to latest, but keep struggling with NMS feature patches. For some reason I can't get the patches to conflict properly (to fix 3-way merges), I used to know how to do this pre-hardfork but no idea what's wrong now. Any help is appreciated!

Task :fork-server:applyMinecraftFeaturePatches FAILED
error: invalid object 100644 f63a5567a2e845de904c2dacfbb875049e3e0c65 for 'net/minecraft/server/MinecraftServer.java'
error: Repository lacks necessary blobs to fall back on 3-way merge.
lucid mulch
#

it will bring in some objects, hopefully decreasing conflicts

lucid mulch
hardy tendon
#

Forking paper yes

#

I'll try that, what if it doesn't succeed and still throws the same error?

#

Do i have to apply the patch manually

lucid mulch
hardy tendon
exotic basin
turbid moon
exotic basin
turbid moon
#

What exactly do you mean by broken? If you run /version ExamplePlugin, what does it look like?

brisk belfry
#

did you check the file inside the jar?

#

maybe you need to do a clean build

turbid moon
#

Just run the clean task and then run build again

brisk belfry
#

yeah

#

just do a clean build

exotic basin
brisk belfry
#

it has do delete the build folder

exotic basin
turbid moon
#

Can you try to do this getup: ```kts
// build.gradle.kts
tasks.processResources {
val props = mapOf(
"version" to project.version,
"description" to project.description,
"author" to project.property("author")
)
filesMatching("paper-plugin.yml") {
expand(props)
}
}

```yml
# paper-plugin.yml
version: $version
description: $description
author: $author
#

Also, sanity check, but could you update Gradle? Just run gradle wrapper --gradle-version=latest and then gradle wrapper again

exotic basin
turbid moon
#

The things you change in that window should not actually do anything if you are building through gradle

#

Can you open up a terminal and actually run ./gradlew build raw?

novel knoll
#

your original configuration looked fine otherwise

proud maple
#

on the topic of processResources, is there any clean way to use a provider for replacement values? expand is doing toString to it which isn't what i want https://pastes.dev/dM5gTDMW2h

tender edge
#

I think blossom can do that

proud maple
#

blossom seems to be what i was looking for, thank you

lucid mulch
#

val version = project.version
and then expand version to the val

exotic basin
exotic basin
# turbid moon The things you change in that window should not actually do anything if you are ...

I know I'm bothering you, but since I'm no longer using artifacts and am using the gradlew build directly, or whatever I have on the right in IDEA automatically in the build/libs folder, I have two JARs. I take the one without the “all” and it goes into the resources where it didn't give the variable because it takes it automatically. Now everything works, but I don't know which method to use for that part of the information, i.e., if they go into gradle. properties or other parts.

novel knoll
exotic basin
novel knoll
exotic basin
final jewel
#

It is tooling that provides you with the deobfuscated server internals

echo kilnBOT
final jewel
#

For more information

exotic basin
#

Now I'll switch to the #paper-dev channel so I can ask them a little more about mapping and shadowjar, since it's a different topic from build logic.

final jewel
exotic basin
turbid moon
lucid mulch
#

next time i shouldnt respond when its midnight thonk

turbid moon
#

All good, happens

novel knoll
exotic basin
bold lodge
#

Guys, any idea why my bukkit/paper classes are not solving?

#

Is this a common issue on IntelliJ?

#

I've had it happen only when the paperMC repo was down, any guesses?

#

Do I have to clean any specific cache?

#

By not resolving, I mean this, idk if I said it properly

lament scarab
#

Generally, make sure that you're using the correct JDK version

#

it knows the packages exist, it's upset about the classes themselves

bold lodge
#

I didn't change anything and I use it daily

#

How did I change anything about the JDK?

#

I'm using Java 22, as always

#

Do I need 23 now?

torn sonnet
# bold lodge I don't understand...

22 was EOLseptember 2024, 23 was EOL march 2025, 24 was EOL september 2025. You should be using 21 or 25.

But, if your IDE is configured for 21 or higher then that shouldn't be the issue. Could just be IDEA needing a brief kick. The Repair IDE feature is useful.

bold lodge
#

I will try, thanks 🙂

#

Nothing is working...

#

For some reason xd

#

I updated the IDE, I updated to Java 25 and I did all the repair options

#

Still have the same issue

#

Oh nvm

#

For some reason I lost like a billion of imports on the project, idk why

bold lodge
#

I think updating the IDE version did the job, but it makes no sense that it just broke for not updating, no?

main mica
#

pretty common

#

older IJ versions often don't work properly with newer JDKs, hardly the first time

cunning folio
#

Hi. I'm trying to use IntelliJ's debug feature with run-task, but for some reason it broke because ⁨⁨fromJson(json, typeToken<T>()) must not be null⁩⁩. It worked fine before. I'm not sure what caused this and how to fix this. Does anyone have an idea?
Stacktrace/log: https://pastes.dev/qzrtNZefTx

smoky violet
#

just run cleanAllPaperweightUserdevCaches to fix it for now

#

I could probably improve the logging when that happens

ornate plaza
#

is there any reason why after i committed my patch files to my forks repository that the project just deleted the patch files? and no longer builds correctly?

#

or was i not supposed to do that

main mica
#

"the project"?

#

You should be able to commit patch files just fine, just make sure to do it in the correct git repo

ornate plaza
ornate plaza
main mica
# ornate plaza you serious?

yes, until you mentioning rebuilding it wasn't clear what deleted the files.
Generally see the contributing.md of Paper for the order of tasks to run. That sounds a lot like you missed a step, or committed the wrong files

ornate plaza
#

il take a second look at it

ornate plaza
zenith stream
#

While using ⁨runServer⁩ in a debug configuration with Debugger's transport set to "Shared Memory" in IntelliJ settings, I'm getting this log:
⁨```

Task :eternalcombat-plugin:shadowJar
Connected to the target VM, address: 'localhost:51826', transport: 'socket'

#

Why is it using ⁨'socket'⁩ transport despite it being set to Shared Memory?

lament scarab
#

You would need to ask jetbrains, we don't control that

ornate plaza
#

You would need to ask paper, they do control that

torn sonnet
blazing harbor
#

how do I update run-paper to use a newer paper build, mine i sstuck at 69

blazing harbor
#

ah nvm I got it, I had to run clean paper cache

smoky violet
hushed sonnet
#

Hi! does anyone have an example plugin that uses paperweight and uses mojang mappings thanks? also with groovy DSL for the build.gradle file, thanks!

echo kilnBOT
hushed sonnet
final jewel
#

or if you insist on using groovy DSL, then it should be just some small syntactic changes, they're very similar for the most part

hushed sonnet
smoky violet
#

kotlin has been the gradle default for a while

ivory quest
#

is there a way i can append my own arguments that paperweight patcher gives git-am

bronze ember
#

what is your usecase?

tough lake
#

Hey, I installed the latest paper upload, a 1.21.11 upload, on my Linux server..
But spear swapping is not working.. WHY?

final viper
#

Please use the #paper-help channel for questions related to Paper

#

Oh, you did, in that case, please don't cross-post 🙂

strong merlin
#

I have a fork of a fork and I would like to add patches directly from another fork?

Like this
paper -> fork1 -> fork2 -> myfork
paper -> fork3 ------------⬏

bronze ember
#

You need to manually apply it and fix conflicts

strong merlin
#

I though of to have the main fork settings and 2 configurable directories first for copied patches and second folder to patch those patches and remove conflicts

pure timber
#

can i include a discord username instead of url/email in a user agent for downloading jars from fill v3?

lucid mulch
#

this should be fine karmuss (https://discord.com)

#

for example

torn sonnet
lucid mulch
#

well i’d personally sooner read a discord dm than check my email lol

#

atleast the message will be read

pure timber
#

5-10

torn sonnet
#

Everything is okay until a bug shows up 😂

bronze ember
#

The idea of the user agents is that if we see too much requests from you, we can't contact you first instead of blocking you straight away

brisk belfry
turbid moon
brisk belfry
#

I was about to ask if this is a serious question

fading wraith
#
A problem occurred configuring root project 'Plugin'.
> Could not resolve all artifacts for configuration ':classpath'.
   > Could not resolve io.papermc.paperweight:paperweight-userdev:2.0.0-beta.19.
     Required by:
         project : > io.papermc.paperweight.userdev:io.papermc.paperweight.userdev.gradle.plugin:2.0.0-beta.19
      > No matching variant of io.papermc.paperweight:paperweight-userdev:2.0.0-beta.19 was found. The consumer was configured to find a library for use during runtime, compatible with Java 21, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.8' but:
          - Variant 'javadocElements' declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its target Java version (required compatibility with Java 21)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.8')
          - Variant 'shadowRuntimeElements' declares a library for use during runtime, compatible with Java 17, packaged as a jar, and its dependencies repackaged (shadow jar):
              - Incompatible because this component declares a component, as well as attribute 'org.gradle.plugin.api-version' with value '9.0.0' and the consumer needed a component, as well as attribute 'org.gradle.plugin.api-version' with value '8.8'
          - Variant 'sourcesElements' declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its target Java version (required compatibility with Java 21)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.8')

* Try:
> No matching variant errors are explained in more detail at https://docs.gradle.org/8.8/userguide/variant_model.html#sub:variant-no-match.
> Review the variant matching algorithm at https://docs.gradle.org/8.8/userguide/variant_attributes.html#sec:abm_algorithm.
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

It's only letting me use 1.7.7 (nothing higher) but I need it to work for 1.21.10.

echo kilnBOT
fading vapor
#

@fading wraith

#

read above

fading wraith
#

oh i was on 8.8

#

updating to 9.3.1 now

fading vapor
#

👍

fading wraith
#

Caused by: groovy.lang.MissingPropertyException: No such property: mode for class: org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator$StubbedFileCopyDetails

#

yikes

lucid mulch
#

i assume it might be due to outdated shadow

#

update your shadow plugin to the new coordinates and latest version

fading wraith
#

8.1.1 is latest

lucid mulch
#

no

#

look at com.gradleup.shadow if i’m not mistaken

#

latest is 9.3.1

fading wraith
#

yup found it

#

im so used to maven, barely touched gradle tbh

#
A problem was found with the configuration of task ':reobfJar' (type 'RemapJar').
  - Gradle detected a problem with the following location: 'C:\Users\name\IdeaProjects\Plugin\build\libs\Plugin-1.0.0.jar'.

* Try:
> Run with --scan to get full insights from a Build Scan (powered by Develocity).
BUILD FAILED in 3s
6 actionable tasks: 3 executed, 3 up-to-date

hahaha gradle hates me

lucid mulch
#

try changing the classifier of the shadowJar task’s output

#

set it to -all or sum, it might just have issues with file names

fading wraith
#
Build file 'C:\Users\name\IdeaProjects\HyriseBots\build.gradle' line: 37

A problem occurred evaluating root project 'HyriseBots'.
> Could not get unknown property 'inputFile' for task ':reobfJar' of type io.papermc.paperweight.tasks.RemapJar.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights from a Build Scan (powered by Develocity).
> Get more help at https://help.gradle.org.

https://pastes.dev/DKk3DM1j0p

#

i feel like i'm being stupid now, i only want to use nms but maven just hates it from what i searched up

final jewel
#

is there a reason you're using remapping, do you mean to post this plugin on spigot?

fading wraith
lucid mulch
#

i would suggest looking at the example plugin repo

fading wraith
#

wheres that

final jewel
lucid mulch
final jewel
#

so you can safely remove the whole assemble block

brave widgetBOT
final jewel
#

for reference

fading wraith
#

yeah see i dont have build.gradle.kts

#

i just have build.gradle

#

i have deadass never used gradle before, always maven.

lucid mulch
#

i hate it

fading wraith
#

polar opposite 😂

#

a pom.xml is so much more friendlier than this

final jewel
#

it is really not that different, you are just much more experienced with maven than you are with gradle

fading wraith
#

yeah

final jewel
#

Gradle has two DSLs you can use for your build scripts, the groovy DSL (what you are using) and the kotlin DSL

lucid mulch
#

my brain is just gradle corrupted from writing tons of gradle plugins kekw

fading wraith
lucid mulch
#

kotlin dsl is generally better to use

#

and recommended

final jewel
#

it is the gradle default however it doesn't really change anything

fading wraith
#

how do i switch on intellij?

final jewel
#

you can keep using groovy DSL, you'll just find some syntactic differences when it comes to examples using Kotlin DSL

lucid mulch
#

its easier to find ur way around but some people find groovy easier due to non typesafe syntax

fading wraith
#

i see

lucid mulch
fading wraith
#

so how do i make the build.gradle work?

lucid mulch
#

and adapt the script if it fails to compile

fading wraith
#

i feel like a rookie lmao

lucid mulch
#

if not you can basically remove all mentions of remap jar

fading wraith
#

nah just paper

#

it's just for my server, won't be posting it.

#

do people even use spigot jars nowadays?

lucid mulch
#

well the two percent that use spigot do kekw

#

but anyway they’ll have to switch to mojmap for next release

fading wraith
#

i wish i could use nms safely on maven

lucid mulch
#

you can delete this entire block

fading wraith
#

done

lucid mulch
fading wraith
#

oh that fixed it

#

wtf

lucid mulch
#

but its not supported here if you decide to go down that route

fading wraith
#

if this works on my server

#

i will crash out

#

ive been at this for hours

#

why the hell is there 4 jars 😂 we only get 2/3 on maven

lucid mulch
fading wraith
#

ew 1.21.8

#

i need 1.21.10

lucid mulch
#

you can change it but yh sticking to gradle is the best way

fading wraith
#

yeah i know

#

i'm gutted

#

i wish i just did it with maven now 😂

fading wraith
#

if this doesnt work im switching to maven

#

maven is so much friendlier

final jewel
fading wraith
#

😂

final jewel
#

check the modified dates

fading wraith
#

well then there should be 100+

#

@final jewel @lucid mulch you two are unbelievable- thank you so so so so much 🙏

#

its been killing me for hours.

hollow cove
#

Hi,
I'm trying to relocate the acf-paper library using ShadowJar plugin, but the build fails with the following error: https://mclo.gs/25CzdTb

Here is my build.gradle.kts configuration:

plugins {
    id("java")
    id("noctra-java")
    alias(libs.plugins.shadow) apply true
}

tasks.named<ShadowJar>("shadowJar") {
    archiveClassifier.set("")
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE

    relocate("co.aikar.commands", "de.noctra.libs.acf.paper")
    relocate("co.aikar.locales", "de.noctra.libs.acf.locales.paper")

    from(project.configurations.runtimeClasspath.get().map { 
        if (it.isDirectory) it else zipTree(it) 
    })

    isZip64 = true
    isReproducibleFileOrder = true
}
hollow cove
#

(I found out that it's not my problem actually, its the problem of this weird plural library, i opened a issue there, and fixed it on my side by repacking the jar with correct file permissions)

rotund pawn
#

does anyone have idea when im trying to build paper pased server?
./gradlew applyPatches

* What went wrong:
Could not determine the dependencies of task ':purpur:paper:filterSpigotExcludes'.
> D:\srv\.gradle\caches\paperweight\upstreams\paper\work\BuildData\mappings

driving me nuts for an hour

#

used correct java version
deleting .gradle or .gradle/cache/paperweight or .gradle in %userprofile% wont help
cloned with --recursive
tried killing previous daemon
tried ./gradlew clean
enabled long path support
tried git submodule update --init --recursive
tried ./gradlew applyPatches --refresh-dependencies

pliant carbon
rotund pawn
#

it's Pufferfish including Purpur

#

and i assume same error will happen in normal Pufferfish too for the Minecraft version im using

pliant carbon
#

try build only pufferfish and only purpur first.
if those two build on their own, its the way you included purpur. that causes the problem.

rotund pawn
#

i tried building original Paper (not Pufferfish or Purpur) but same error comes

Thyristor_Chopper@DESKTOP-5RCIRV2 MINGW64 ~/Downloads/PaperSpigot-fork-fix-main
(master)
$ ./gradlew applyPatches

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':filterSpigotExcludes'.
> C:\Users\Thyristor_Chopper\Downloads\PaperSpigot-fork-fix-main\work\BuildData\
mappings

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3s


rotund pawn
#

any help would be thankful

#

did the PaperSpigot devs change the repo url again? it once changed from papermc.io/repo to repo.papermc.io so i had to apply that to build.gradle.kts last year but did they change the repo url once again?

proud maple
#

no, and it's also been called just paper now for a decade

#

the version you're trying to build is also quite old, pre-hardfork at the latest, try adding the --stacktrace option like it suggests to see if it produces anything useful

rotund pawn
#

stacktrace also says
org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':filterSpigotExcludes'.
and the reason im using this version is because i made many modifications to the code and im about to make my own patches and post it on Github because its gpl but i cant get it to first build the unmodified original PaperSpigot code.
./gradlew createReobfPaperclipJar works fine in my previous build working directory but im stuck in applyPatches in a fresh new build workspace

#

the PaperSpigot devs might have removed something from the server for this version recently. it fresh built fine last year after fixing repo.paapermc.io in build.gradle

#

the version you're trying to build is also quite old
it's relatively not that old, it's 1.18.1

#

ill try buillding Spigot first using BuildTools since this will add some jars in local maven repo. will see if this changes anything

rotund pawn
#

this seems to have something with paperweight

novel knoll
rotund pawn
#

applyPatches worked fine last year

#

so annoying they keep removing old dependencies

#

but where is filterSpigotExcludes task defined anyways? its not in PaperSpigot's build.gradle.kts

rotund pawn
#

i got two new questions

  • since Spigot 1.18.1 still builds fine will it be possible to build PaperSpigot 1.18.1 using BuildTools if i apply PaperSpigot patches?
  • can PaperSpigot JAR built with Spigot BuildTools be distributed publicly?
#

it is, the build tooling has changed a lot since then, project setup is a completely different story than then, especially for forks
@novel knoll oh wait by the way the same error Could not determine the dependencies of task ':filterSpigotExcludes' also happens in PaperSpigot 1.20,4 which is more recent version.

novel knoll
#

it is more recent than 1.18, but it is also pre-hard fork, which is when the tooling changed a lot

lament scarab
#

Do note that those versions are basically unsupported, as is windows for all intents and purposes

#

try a shorter build path

novel knoll
#

or that git option, erm

lament scarab
#

outside of that, you'd generally need to diagnose why it's failing yourself

rotund pawn
#

i also tried that git or short paths anyways. just i'd now try using BuildTools if distributing paperspigot jar built from it is ok

lament scarab
#

I mean, you can't get a paper jar from buildtools

rotund pawn
#

if i apply Paper patches in it

#

i think i would have to exclude 0001-Setup-Gradle-project.patch

rotund pawn
#

anyways is it legally ok to distribute PaperSpigot jar built from Spigot BuildTools if i apply Paper patches?

lament scarab
#

No

rotund pawn
#

hmm than maybe i should only post the patches on GitHub?

rotund pawn
#

hmm i think i figured out why 1.18.1 kept failed

rotund pawn
#

finally fixed

rotund pawn
#

in paperweight rebuildPatches task is it possible to make it ignore encoding changes, indent changes(4 spaces -> tab) and CR LF -> LF changes?
i think the very latter can be done by core.autocrlf but not sure about others

#

the second one could be done by git diff --ignore-space-change but not sure if it can be used with paperweight

lament scarab
#

paperweight does not support that

#

the expectation is that you don't break that stuff, like with basically every single other codebase out there

rotund pawn
#

oh ok

#

some patches has zero difference at all tho

cerulean stag
#

Hey! I have a fork of paper currently on version 1.20.1 using the v1 patcher, I am trying to update to the v2 patcher along with the minecraft version to bump it up to 1.21.11. I already have some patches for some files, but they are failing with the following message:

error: invalid object 100644 41b7310a514bf4d42c501e4bffe04008bda2541f for 'src/main/java/org/bukkit/block/Block.java'
error: Repository lacks necessary blobs to fall back on 3-way merge.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

***   Please review above details and finish the apply then
***   save the changes with `./gradlew rebuildPatches

What's the best way to resolve these issues?

#

I've been reading through some similar questions here and I saw something along the lines of reverting to the last working commit on 1.20.1, applying patches, then updating doing something. But I'm a little lost

lament scarab
#

I mean, iirc the hack was to basically have a patched up -api folder added as a remote to your project so taht git could reference it for the 3way, otherwise, you would need to manually resolve everything

#

I think that there was like a variable in the gradle properties file that might disable some filtering during updates

cerulean stag
#

In the case of manually resolving, what would be the best way to do that?

#

Just go one by one down the patches and make new patches manually?

lament scarab
#

Basically, yes

cerulean stag
#

I see, that's sort of what I assumed haha. Thank you for the help!

stuck pilot
#

I've been looking into forks of paper, and after much confusion I eventually realised that paper's patches were included via paperweight. Are there any docs at all about how this works?

final jewel
stuck pilot
#

yeah

final jewel
#

it isn't necessarily something you need to know in order to make your own fork if that's the line of thought

stuck pilot
#

or is my only option to copy from other forks to figure things out?

stuck pilot
final jewel
#

other than that, you're kind of expected to just know how to navigate paperweight's source if it comes down to it, but often enough just having some degree of understanding of gradle and looking at the example repo should do

grizzled river
#

is folia not an option on the hangar publish plugin?

proud maple
#

folia support is just a tag you can select in the project's settings

grizzled river
#

ty

autumn badger
#

hey guyss!!
i'm trying to build paperweight-examples(1.21.11).
and i modified the classes in the paper-api and paper-server paths, now how do i create a patch file?? 🤔

already tried rebuildPaperPatches! but nothin happen 🤡

gentle viper
#

iirc

lucid mulch
#

is paperweight planned to change its minimum supported version of gradle to 9.4.0?

#

i’d greatly appreciate if that’s the case

novel knoll
#

does something not work on that version of gradle? what's stopping you from using it?

lucid mulch
#

regardless there are a lot of improvements that could help paperweight itself

#

were it to switch to that version

#

-# this change would be a great fit for the 26.1 branch as its already making breaking changes to paperweight

#

imho

fringe plank
#

elo

final jewel
#

besides, it didn't really introduce anything mission-critical? Only thing of note is the java 26 support

daring trail
#

not mission critical but the new progress bars are cool

autumn badger
cerulean stag
#

I've currently set up a project using patcher version 2.0.0-beta.19 and have set up my project and all that gradle-wise properly according to some other forks that use patcher v2. With that said, when I apply patches to my server module I get:

Project with path ':ForkProject:paper-api' could not be found.

Which is correct, because in my forkproject-server directory, the upstream build.gradle.kts file has the project as paper-api and not forkproject-api which is also correct. How can I create a patch for that build.gradle.kts file if it is being git ignored (which from other forks and from examples, it should be, because it's an upstream file to paper)?

#

My apologies if this is a dumb question, I just can't seem to figure it out haha.

turbid moon
cerulean stag
#

Oh my... I'm a complete idiot.

#

Thank you so much! This has been driving me nuts for hours.

teal cloud
#

How do I make a project with multiple server software plugins while in the same folder and same gradle project

lusty canyon
#

Hi, since today my project's build started failing on:


FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Cithare'.
> Failed to create service 'paperweight-userdev:setupService:c9c8dd4f27fdeedc434bee64bc6d860a34182706de5704f127602e7da10a1a71'.
   > Could not create an instance of type io.papermc.paperweight.userdev.internal.setup.UserdevSetup.
      > Unknown dev bundle config type: io.papermc.paperweight.userdev.internal.setup.v7.DevBundleV7$Config

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights from a Build Scan (powered by Develocity).
> Get more help at https://help.gradle.org.

BUILD FAILED in 38s

I am guessing it is because the newest snapshot is not compatible with 1.21.11 and is already being prepared for 26.1? Or am I doing something wrong?

pallid elbow
#

It's been so long, can somebody help remind me how to solve pulling upstream and having a conflict on my fork-api gradle build file? ```> Task :applyPaperSingleFilePatches FAILED
Patch /home/cryptite/dev/Slice/fork-api/build.gradle.kts.patch failed:
[DEBUG] Patching: paper-api/build.gradle.kts
[DEBUG] Hunk 0: EXACT: @@ -89,9 +89,12 @@
[DEBUG] Hunk 1: EXACT: @@ -101,6 +104,18 @@
[DEBUG] Hunk 2: EXACT: @@ -183,7 +198,7 @@
[WARN] Hunk 3: FAILURE: @@ -216,11 +231,11 @@

cinder ember
#

That will create a rejected patch, look at the lines that were rejected and reapply that

#

Then rebuild the patches

lusty canyon
pallid elbow
smoky violet
#

you shouldn't use the snapshot unless you have a specific reason to

sudden verge
#

why are the Minecraft java classes are orange, and nothing appears to change for git?

proud maple
#

you're looking at the root git repository when there's actually multiple git repositories involved, i don't know if intellij's git client lets you change which one you're looking at but the cli works as well

sudden verge
tender edge
#

IntelliJ lies, the only truth is git cli

sudden verge
tender edge
#

you could try adding other git roots but like, who has time for broken git frontends

#

just learn the actual tool

bronze ember
#

Fwiw the paperweight setup is validated to work using intellijs git UI

gusty mantle
#

trying to update my fork to 26.1

#

did i forget to do something or what

#

i can see it's the sha from updatingMinecraft

#

ok, managed to fix it

#

just commented out updatingMinecraft lol

cinder ember
#

<@&748618676189528155>

proud maple
#

(handled)

ocean sierra
#

someone knows if there's an alternative for disablePluginJarDetection() on run-task paper?

GitHub

Gradle plugins adding tasks to run Minecraft server and proxy software - jpenilla/run-task

#

I'm trying to obfuscate my code and I want to test the obfuscated JAR file without creating another server

novel knoll
#

alternative in what way?

ocean sierra
#

like i dont want to the task to use the plugin jar from shadowJar

#

i want it to use the ofuscated one, but that method doesn't exist on latest version of the plugin (at least for me)

novel knoll
#

then you'd use that, and add the output jar manually to the pluginJars file collection

ocean sierra
novel knoll
#

something like

runPaper {
  disable...()
}

tasks.runServer {
  pluginJars(obfTask)
}
final jewel
#

that method definitely exists

novel knoll
#

it's on the extension

#

not the task

ocean sierra
#

so something like this?

final jewel
#

yes

ocean sierra
#

oh ok i was thinking that the method was removed or smth

#

thank you guys

split yarrow
#

Yo is there a way i can get clean mc source without paper/moon rise patches

#

The de obfuscated jar is hard to search through since IJ doesnt index .class files

proud maple
split yarrow
#

tysm i forgor mache existed

proud sinew
#

hello, any idea how to fix

* What went wrong:
A problem occurred configuring project ':swm-nms-v1_21'.
> Failed to create service 'paperweight-userdev:setupService:f9d2b05ff1229fb5bc38d36f191c4e3a8bd86f8146f775916579ca6f7cba527a'.
   > Could not create an instance of type io.papermc.paperweight.userdev.internal.setup.UserdevSetup.
      > Unknown dev bundle config type: io.papermc.paperweight.userdev.internal.setup.v7.DevBundleV7$Config
plugins {
    id("io.papermc.paperweight.userdev") version "2.0.0-SNAPSHOT"
}

repositories {
    mavenLocal()
    maven { url = "https://repo.papermc.io/repository/maven-public/" }
}

dependencies {
    paperweight.paperDevBundle("1.21.11-R0.1-SNAPSHOT")

    compileOnly(project(":swm-api"))
    compileOnly(project(":swm-nms-common"))
    compileOnly(project(":swm-classmodifier"))

    compileOnly("commons-io:commons-io:2.16.1")
}```
turbid moon
proud sinew
#

it doing something

#

yes that works

#

tysm

turbid moon
#

np

chilly needle
#

Hey, when building with paperweight-userdev 2.0.0-beta.19, the remapMinecraft step fails for dev bundles that require JDK 25 (e.g. 1.21.4–1.21.9). The bundled codebook-cli (1.0.15) uses ASM 9.6 internally, which only supports up to Java 24 (major version 68). JDK 25 produces class files with major version 69, causing:

java.lang.IllegalArgumentException: Unsupported class file major version 69
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:200)
at dev.denwav.hypo.asm.AsmClassData.readFile(AsmClassData.java:296)

Would it be possible to update Codebook's ASM dependency to 9.8+ (which adds Opcodes.V25 for Java 25 support)? This currently blocks building any adapter that targets MC versions with JDK 25 dev bundles.

static urchin
#

I think our general stance was that you can change the java launcher used for this to a 21 jdk. The task should have a launcher property you can configure NODDERS

lament scarab
#

The entire decompilation stuff is JDK version dependent, and so paperweight supporting newer versions than MC does for that stuff is generally not a huge thing for us

final jewel
#

Luckily 26.1 updated to 25 so you should be able to use jdk 25 just fine in the future

lament scarab
#

I mean, the asm lib might support that, decompiling existing versions with 25, will not

turbid moon
#

There's a section on it on the docs even

stuck pilot
#

I'm in the process of refactoring my plugin into modules, but I'm having an issue.

Package 'com.mojang.brigadier' is declared in module 'brigadier', but module 'RaycastedAntiESP.platform.paper.main' does not read it

Obviously, this error message prompts the solution of adding requires brigadier; to module-info.java, but that then results in the error error: module not found: brigadier
requires brigadier;

#

How do I fix this?

turbid moon
#

Plugin dev is simply not module-ready

stuck pilot
#

That was the conclusion I'd sadly kinda worked out

turbid moon
stuck pilot
#

Bit annoying, I wanted to use modules so i could have a sealed interface with impls across packages

turbid moon
#

But you will run into module-info.java problems once you try to use Adventure things anyways

#

Or other library code

#

There was also some work around which hacks a module-info into your dependency jars manually, but that's super hacky

lament scarab
#

it's a dependency hell where everything upstream needs to support it and then you shade it all into a single jar so what did you even gain situation

turbid moon
#

Yeah ^^. The one thing I love about module-info.java is that you can @NullMarked the whole thing and never have to worry about nullabilty, but it's not worth the effort

winter glacier
#

Is there an easy way to port the same patches from a paper fork to a folia fork somehow in an easy way? I am currently maintaining a paper fork for my own network with some specifically customized stuff for the network, but now I would like to have folia too with these customizations. Is there any easy way to solve it?

final jewel
#

you could always cherry pick the commits from the paper fork over to the folia fork, given you fix any merge conflicts if any

#

if you wanted a single source of truth it'd be more annoying though, perhaps making a separate module and then wrangling paperweight into taking it as patches source

winter glacier
#

but since folia is a fork of paper, couldnt you configure paperweight to let folia be a fork of my paper fork instead of paper directly? then I would just put my fork inbetween somehow

winter glacier
final jewel
#

not sure if you can just change the ref in upstreams.paper in order to do that, hopefully jmp or someone more knowledgeable in paperweight can tell you exactly

winter glacier
#

would pinging him be a right thing to do? I always have the feeling nobody ever sees this channel

glass warren
#

No, don't ping staff for questions like this.

final jewel
#

jmp frequently looks over this channel, if they don't they're probably just busy

#

for now, you can try playing around with setting the ref value and see if that works

winter glacier
#

I prolly have to make my fork public on github then, right?

final jewel
winter glacier
final jewel
#

I was thinking you were trying to use your local git repo for it

winter glacier
#

only problem I have now are the invalid object ids in the patches

#

since I am modifing classes of paper first, the object id changes and if folia then tries to edit the same class, it isnt the same object id anymore

#

any idea how I would fix that?

#

I really hate these object ids since they are failing so many times

final jewel
winter glacier
brave widgetBOT
winter glacier
#

its exactly the one of the v2-fork-of-fork branch just with my names replaced

final jewel
# winter glacier

just to be sure, shulker is your paper fork right? Because if that's the case then I think we got a little confused

winter glacier
#

yeah shulker is my paper fork

final jewel
#

you'd want to use fork-of-fork on the folia repo, then have the forky-server point the activeFork to shulker if I am correct

winter glacier
#

so I would fork folia?

In that case folia would be fork and my thing would be the fork-of-fork so forky, right?

#

and there I would replace the paper repos with my paper fork?

final jewel
#

in this case folia would just be folia, and your folia patches would be in forky-api/server, including the patch to change the paper base to shulker

#

or that would be the idea

winter glacier
#

would folia be forky in that case?

final jewel
#

nevermind, I was thinking that maybe you would have to edit the forky-server patch on build.gradle.kts but that doesn't seem to be the case. Not sure what would be the next step here anymore lol. I'll try to get a similar setup working

winter glacier
#

What I thought is:

Folia currently uses the v2-fork setup, so it directly forks paper.

Then, I clone the folia repo and change the complete setup to use the v2-fork-of-fork setup. In that case, fork is shulker and forky is folia.

Just to be sure here what we both mean

final jewel
#

What I meant was to just take v2-fork-of-fork then set folia as the base fork, then in the patches modify the folia paper base to be your fork

winter glacier
#

Ahh okay that would work too I guess

winter glacier
winter glacier
#

So, I set it up, but I have some errors/points where I don't know how to proceed correctly. In my opinion, I would need two registered upstreams in the root build gradle, since I don't really know how to provide the information where my paper fork is located if thats not the case. Here are my files:

(The fork of Folia is called prism, the fork of paper is called shulker)

build.gradle.kts: https://pastes.dev/jqYzIsnXGF
prism-server/build.gradle.kts.patch: https://pastes.dev/c5hc6I3nbS
prism-api/build.gradle.kts.patch: https://pastes.dev/DTUnpWXH0w

When I register two upstreams I get: Cannot add task 'applyUpstream' as a task with that name already exists.
When I only register folia as upstream, I don't know how to tell paperweight where shulker (my paper fork) is located, since folia would need to pull from shulker instead of paper.

lucid mulch
#

<@&748618676189528155>

teal cloud
torn sonnet
plucky patrol
#

Is this channel where I ask for help developing my paper plugin?

#

I'm confused

plucky patrol
#

Ah, somehow I missed that entire category

#

thanks!

trail pilot
#

How do I update paperweight-userdev

Could not resolve io.papermc.paperweight:paperweight-userdev:2.0.0-beta.19

echo kilnBOT
turbid moon
#

@trail pilot ^^

lunar whale
#

first time having trouble compiling 26.1 :/

#

branch origin/dev/26.1 is correct? O.o

static urchin
#

dev/26.1 is the branch yes

#

with the increadible obvious note that we haven't published paper as alpha for a reason

lunar whale
#

Execution failed for task ':paper-server:setupMacheSources'.

#

its fine for me, i can wait *nailbite* thing is, packetevents is waiting for paper, and same plugin is kicking on proxy every tick on testing spigot
take your time to make it good as always, you are the gods

#

setupMacheSources is java missmatch, i think

OpenJDK Runtime Environment (build 25.0.1+8-Debian-3)
OpenJDK 64-Bit Server VM (build 25.0.1+8-Debian-3, mixed mode, sharing)```
is wrong?
lunar whale
#

nevermind, i wait... xD

ornate kettle
static urchin
#

isn't v2 deprecated? I don't think it is receiving new builds anymore

proud maple
#

that is indeed the case

ornate kettle
#

ty

winter glacier
final jewel
winter glacier
reef rock
#

Hello,

I'm new on MC and on paper. I tried building a sand dupper on the server and it's not working. Is this normal or should it work? The configs on the server are all on "true".

Thanks

final viper
teal geyser
#

How do I build Folia now? What are the commands? ./gradlew build and all ?

main mica
#

just like Paper, see the paper readme

turbid moon
#

I am trying to use paperweight userdev with jmp's world structure migration PR, however I cannot seem to get it to work. My build.gradle.kts is rather simple, being just this: ```kts
plugins {
id("java-common")
id("io.papermc.paperweight.userdev") version "2.0.0-beta.19"
}

dependencies {
paperweight.paperDevBundle("26.1-R0.1-SNAPSHOT")
}

`java-common` is a convention plugin which looks like this: <https://pastes.dev/3ff7USxOJQ>.

When I use paperweight version `2.0.0-beta.19`, it complains about the data version `'8'` being too high for the plugin to handle. Sure, makes sense (log: <https://pastes.dev/OCxFTYuanW>).

If instead using the snapshot version `2.0.0-SNAPSHOT`, it dies at the `:paperweightUserDev` task during `vanillaServerDownloads` (log: <https://pastes.dev/47ycfqKfHh>). So what is the correct way to use userdev with the 26.1 snapshot bundle from that PR?
#

For sake of testing I also attempted to move the PR maven repo to the top of the repositories block, but that did not yield a positive result, it still fails in the same spot

proud maple
#

try using 2.0.0-SNAPSHOT, hopefully that has a userdev version deployed aswell

turbid moon
#

I did, that unfortunately did not work

proud maple
#

oh right you said that

turbid moon
#

I kinda feel like the auto-provisioned JDK in the log might be part of the problem, but I cannot really see why that would happen. This is my settings.gradle.kts in case it matters: https://pastes.dev/fgPZcVsLAj

proud maple
#

can you get a log when using that version and using --stacktrace

turbid moon
#

Sure

#
Caused by: java.lang.IllegalStateException: No such download 'server_mappings' in version manifest
proud maple
#

looks like that part was missed during the update

turbid moon
#

Well, I am sure jmp will fix it in due time

#

I will postpone my plugin update until then though

smoky violet
#

nothing was missed

#

userdev is not ready and we didn’t claim it was anywhere

proud maple
#

my bad, i saw the 26.1 commit touched parts of the userdev folder so figured it might've been included

turbid moon
#

Alright, fair, thanks for the clear up

turbid moon
#

Yay new problem. I revert back to 2.0.0-beta.19 and my previous dev bundle version used to be for 1.21.8. Works perfectly fine. However when I update it to 1.21.11, I get a cute little configuration cache error.

build,gradle.kts: ```kts
plugins {
id("java-common")
id("io.papermc.paperweight.userdev") version "2.0.0-beta.19"
}

dependencies {
paperweight.paperDevBundle("1.21.11-R0.1-SNAPSHOT")
}


**Build logs**: <https://pastes.dev/aOAjrLhhq7>.

What might I be doing incorrectly?
smoky violet
#

idk

#

maybe bad gradle caches somewhere

#

thats before it runs the paperweight pipeline

turbid moon
#

Well, deleting the .gradle folder did nothing at all

lament scarab
#

That's generally down to the local maven repo having the adventure artifacts

#

it seems to basically cause some issues it resolving some gradle specific metadata

remote frigate
echo kilnBOT
remote frigate
# echo kiln

already did that, gradle on version 9.4.0, its the latest version of userdev and already readed the docs

proud maple
#

you are currently using 8.8 in that paste

remote frigate
proud maple
#

in the settings

remote frigate
#

ye, doing that rn, thanks

lucid mulch
#

not sure where to post it but the 26.1 dev branch doesnt have all the commits from main in it

#

i believe it is two commits outdated

glass warren
#

There's lots of stuff still being worked on.

lucid mulch
#

im just saying that its outdated in case someone missed it

#

as the updating minecraft property has been disabled

remote frigate
# remote frigate ye, doing that rn, thanks

just a disclaimer for anyone in the future with the same issue, when changing to the gradle, it requires the gradle installation folder not the executable that you use... Mine was at "/usr/share/java/gradle"

lucid mulch
#

these seem to be missing

smoky violet
#

known

cinder fern
#
plugins {
    id 'java'
    id "io.papermc.paperweight.userdev" version "2.0.0-beta.19"
    id "com.gradleup.shadow" version "9.4.1"
}
repositories {
    mavenCentral()
    maven { url = "https://repo.papermc.io/repository/maven-public/" }
}
dependencies {
    paperweight.paperDevBundle("1.21.11-R0.1-SNAPSHOT")
}```
"Unable to resolve a dev bundle, which is required for paperweight to function.
Add a dev bundle to the 'paperweightDevelopmentBundle' configuration (the dependencies.paperweight extension can help with this), and ensure there is a repository to resolve it from (the Paper repository is used by default)."
why 😭
#

gradle 9.4.1

elfin sky
#

fyi: I get this error using 2.0.0-beta.20. I got it fixed locally by adding:

is DevBundleV7.Config -> SetupHandlerImplV7(
    parameters,
    bundleInfo as BundleInfo<DevBundleV7.Config>
)

to SetupHandler.kt

cinder fern
#

what 😭

#

I hate this error because i've seen it maybe ten times in my life and it always just randomly fixed for some reason but not now

smoky violet
#

beta 21 building now

elfin sky
#

Nice, thank you

drifting torrent
#

appreciate it

elfin sky
#

Finally I can build my plugins with 26.1.1 support in my pipieline 😄

drifting torrent
#

keep getting this but idk where id be using reobf?
tried adding those paperweight blocks to see but same thing

smoky violet
#

it's something in your build

#

paperweight does not auto add reobfJar to any lifecycle task, you're either doing that or manually invoking it

drifting torrent
#

not sure where id be doing so since its not found anywhere in my code pepothink hmm

#

ok its something in my setup yeah

tasks.named("reobfJar") {
    enabled = false
}
``` fixes it
guess ill go and fight gradle for abit whenever i care to and properly fix it ![rikothumb](https://cdn.discordapp.com/emojis/773558035913769000.webp?size=128 "rikothumb")
winter glacier
#

what paperweight version is the correct when forking paper on 26.1?

winter glacier
glossy fox
#

Hey,
I know there is the "paperweight-mappings-namespace" (https://github.com/gecolay/GSit/blob/main/build.gradle.kts#L58) setting to tell paper, if it needs to remap a plugin.
But because i would like to support multiple versions I have 1.16.x to 26.1.x in my plugin where e.g. the new 26.1.x is compiled with java 25 to a folder in my jar.
If I use this plugin on a older paper server e.g. 1.21.4 with java 24 I now get a stack trace on startup, which tells me, that paper can't remap the 26.1.x folder in my plugin (which is obvious, since this folder requires java 25)

So my question: Can i exclude just a single folder, not my complete plugin from the remap in older server versions, so that server owners with a older paper version can still use it?

#

Example startup stack trace for a java 25 class remap error, if i start the server with java 24:

final jewel
glossy fox
final jewel
#

it only gets more annoying for versions like 1.21.10 (or was it 1.21.9?) which I think never received remapping support given how short the timespan between releases was

glossy fox
final jewel
glossy fox
#

I would just need a setting to tell paper: "please do not remap this one folder inside my jar" 😅

final jewel
#

that just isn't possible unless you were to fork Paper, because older versions aren't being changed anyway

torn sonnet
#

how much are you doing in these NMS modules that it would actually bloat?
Also, nearly nobody running outdated servers gets updated plugins. I've been dropping outdated support for a while and only get complaints for like the most recent old version only.

final jewel
#

though I guess you could take a look at source remapping, there's a branch in the paperweight test repo that does it

smoky violet
#

thats for one time migrations and is not updated

#

plus lynx cooked the branch

final jewel
#

welp, there goes one option lol