#build-tooling-help
1 messages · Page 27 of 1
As well as the artifact from the exact GitHub workflow that failed, showing it is 11.9mb:
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]
You might need to point it towards the correct path, like Purpur does here: https://github.com/PurpurMC/Purpur/blob/ver%2F1.21.11/purpur-server%2Fbuild.gradle.kts.patch#L46
i already got that, the log4jPlugins sourceSet does compile and is in the final jar but not the dat file
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
kapt gradle plugin was causing it not to work
Because those are from minecraft feature patches applied over the mc tree
seperating them would just create complications
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.
Is there a reason you're trying to build an old version vs downloading it from the website?
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.
As lynxplay said, the downloads API is what you'd want if you're trying to grab the most recent build.
Do be aware that we strongly advise against auto-updating. We never know when a build could introduce a flaw or bug that could cause issues.
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.
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
don't think you need to do anything but just, press the intellij debug run button
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
pretty sure most of these options are only needed if you are not using runPaper
in reality, you only need debug = true in there, I explicitly configure all of the properties because I change them sometimes
debug = true bugs out for debug run configurations in IJ, or it does for me anyway
It's a final property
Ye idk, I literally plug nothing in there
if you run it via intellij, just using the debug button is enough, I mention that in the message too
you can do setDebug instead, it is the same deal
it is probably getting confused between a function call and actually setting a property
There is no setters/getters with the kotlin DSL, it just exposes it as a property
Yes, there are, but kotlin does the same thing it does for every get/set method and turns it into property access
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
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
I don't know but I tried this myself on a plugin of mine and it works fine
Is there a proper channel to request support with Hangar? This seems to be an issue with Hangar itself, but I was directed here.
Thank you, looks like I didn't have the channel selected.
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"]
you probably want to update the foojay resolver plugin to the version that supports gradle 9 if you're going to run gradle 9
thank you
why is it git ignored? how do i do minecraft patches then
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
see the contributing.md file. it explains the patch system
what did i do wrong? minecraft folder is not meant to be completely git ignored
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
add it as a VSC dir in IJ
how
Version Control > Directory Mappings
and where is version control
sorry
Found it
Thanks
now its stuck in git am for no reason
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.
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
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
^ https://github.com/PaperMC/Paper/blob/3ebc5b3320924e9122903dfd1f11abcf897300e6/gradle.properties#L2-L6 that's probably why it's failing
yeah that's it, just tested locally
Yeah okay that did it, thank you very much Emily
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)
Anyways there we go, updated both the v2-fork branch and the v2-fork-of-fork branches:
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!
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
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)
fuzzy is a bit 50/50, it sometimes also drops changes silently lol
How could I go about editing the build.gradles.kts.patch's? I cant edit the patches directly.
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
cant I just ./gradlew rebuildPurpurSingleFilePatches or rebuildPaperSingleFilePatches?
yep. Not sure which of those two you need to use for a fork-of-a-fork, but that is the correct task generally
Purpur is a fork of a fork of a fork. Many forks
hm, its not working.
I firt applied all patches, then I rebuild the patches.
Applied all the patches again. After that I updated the Mcversion and paper/purpur ref to the latest.
Applied all the patches again. now it giving me the same patches reject junk.
I think im doing something wrong.😭
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)
paperweight is at "2.0.0-beta.19"
but I keep seeing paperweight 18 when applying patches
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)
my fork is based off this
https://github.com/PurpurMC/Tentacles
I can't provide support for that
will you able to help me with this then
https://github.com/PaperMC/paperweight-examples/tree/v2-fork
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
You should really talk to the purpur folks about this stuff then.
they keep ignoring me when I ask
primarly this issue is haunting me
Your last message in their server is in NOVEMBER
maybe you're forgetting to press send
setupMacheSources failing would generally be down to a java version mismatch
(outside of some decompiler version mismatch)
Mismatch? Im coding in 21, I rebuild the patches via the paperweight-patcher. a bunch of files appeared and then becames rejects
recommendations?
21
im using 21. maybe it like temerin?
what JDK are you using to run gradle with?
Btw this is what no-ping means @sudden verge disable that @
Oracle OpenJDK 21.0.8
my bad
ima try tomorrow then, If I dont get an answer. Im coming back here.🙃
- clone
PaperMC/Paper-archivever/1.20.4 ./gradlew applyPatches- 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?
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
omg....
there is a couple ways, either using bash's diff command and setting the output to a .patch file or using Git's system but that requires both files to be tracked
thats not the correct way
okay
iirc one of the rebuild commands does this
уeah, the single file patches one does it
but i dont blame him, i also used the output of diff for modifying those patches at first 
until jmp corrected me here when i advised that to someone
this change didnt go into .19, it was merged a month after .19's release
it will be in the next release
your error points to userdev possibly being outdated
ensure you go through all the steps here
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.
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
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)
I do commit amend, is that not the right thing to do? I do git add . and the amend commit
No, amend amends the last commit
that's why your changes are on the last patch file rather than in a seperate one
ooh, okay, then what should I do instead?
you just commit normally
ok, thanks. Now I just have to redo all the patches
How do I remove these annoying warnings when building a paperclip jar?
Outside of disabling warnings in general you can’t
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
You would just use the standard build task
Which one is this? I've tried running all of them
(So for clarification:
- I ran
applyPatchesand it generated abuild.gradle.ktsinfork-server - I then modified
build.gradle.kts - I then tried running every
:fork-server:rebuild...Patchestask but none of them modify thebuild.gradle.kts.patch
)
.
Which one is that?
rebuildPaperSingleFilePatches
read what ./gradlew tasks says
I believe
only if they fork paper
Based on the fact that they are using :fork-server, I think so
thats why its good to advise to read what the tasks output actually says
Yeah ofc, that's the get-go solution ^^
yh but jmp got kinda mad at me some time ago when i gave out task names so i started telling people to read

People who can’t be bother to read the doc probably shouldn’t be making forks
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)
There is a task specific for single file patches
Do I need to stage build.gradle.kts somewhere maybe? I felt it should be in .gitignore
no, we told you its the single file patches task
the gitignore from the template already contains all it is supposed to contain
Ah it's rebuildPaperSingleFilePatches - Rebuilds all paper single-file patches
yes
Thank you! It was in the top module, I was looking in each specific module since that's where every other patching task lives
Yes exactly
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
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
True
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?
Fork stuff is pretty documented on the example repo(s)
Do you mean https://github.com/PaperMC/paperweight-examples ? I can't find any documentation there (apart from the necessary files just being there)
Not that I mind, but just trying to make sure I don't miss any place to reference
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
afaik it intentionally isn't documented

I mean I had the same impression.
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
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
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!
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?
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
Oh, my idea is that it can be used to improve the success rate of 3-way merge.
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
Yeah that might be the case, at first I understood it as a way to update pre hf to post hf
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!
it is only applicable however for paper itself
it isnt exposed to forks
so it will cause failures
but why did jmp mention this when answering paper fork question? I just wanted to confirm, not to accuse.
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
Let me see where I should add the old repo. Thank you!
Is it possible to add Linear format instead of mc/anvil for Folia? Im making a paper/folia fork that implements linear format just like LinearPaper.
https://github.com/Gr1mly4Memes/forge
I mean, sure
is there like anythin I should look out for?
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
alright, I mean I was looking the code of this.
https://github.com/GideonWhite1029/Horizon
I just copied the code and now my fork just spits out errors and corrupts the worlds 😭
well, you can't just copy code and expect it to work
true I guess.
it also seems that they ported the old linear patches
would recommend starting from scratch to implement linear v2 instead
ok gotcha, is there a refrence I can look?
well, reference would be the old linear implementation in LinearPaper or that fork you linked above 😛
perhaps newer linear?
you'll just have to figure out what changed implementation-wise between linear 1 and 2 by looking at the repo: https://github.com/xymb-endcrystalme/LinearRegionFileFormatTools/compare/master...linearv2
they seem to have a document detailing both v2 and v1 details, so you can probably work it off that
ok, im just going to have a fun day implementing this
yeah, it does soon like quite the pain in the ass to implement given the only reference implementation is on python
yeah
oh it is? 
..
anyone can help me slove my iss? It's here: https://github.com/dmulloy2/ProtocolLib/issues/3586
sr this is my first time
that is not the correct format for a paper-plugin.yml, sounds like you want to use the plugin.yml format
though I would recommend just using the normal plugin.yml given you aren't using any of the paper plugin features
thx y so much
i cant sync the project when adding paperweight
https://pastes.dev/oIi2k8TsY0
Your Gradle is outdated, update your Gradle
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
that sounds reasonable, try it
seems to work thanks !
"just" had to use the publish all instead of publish plugin gradlew task 
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)
}
//...
}
I want to split my plugin into multiple plugins as modules, but maybe it isn't needed
We have an example on how to use paperweight in a multi-module project, you should give that a look: https://github.com/PaperMC/paperweight-test-plugin/tree/multi-project
test plugin for paperweight-userdev. Contribute to PaperMC/paperweight-test-plugin development by creating an account on GitHub.
https://mcpaste.io/1974c27587b13fe2
Maybe someone knows that issue could be causing this?
A easy to use Paste site for Minecraft Server logs.
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
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
Yes, that would break it
And how to correctly replace the file?
You don't
replacing the file breaks the build
if you want to rename stuff you would need to override the jar tasks output
Then change the name of the jar task
tasks.shadowJar {
archiveFileName.set("ZCAPI.jar")
}
tasks.jar {
archiveFileName.set("ZCAPI.tmp.jar")
}
Like this?
sure, I guess
you can also disable the jar task @polar edge, that should fix it too afaik
enabled = false or sum
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
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
that's fine, that's what I do too
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
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?
its well explained in the contributing.md, there is a dedicated section for it https://github.com/PaperMC/Paper/blob/main/CONTRIBUTING.md#modifying-per-file-minecraft-patches
Anyone, uh, tried using AI to help them upgrade their patches to update their fork to latest mc version?
i can't wait for AI generated commit and file hashes
Is there a 1.21.11 version of this https://github.com/PaperMC/paperweight-examples/tree/v2-fork or has forking changed at all?
edit: nvm i see the PR
Contribute to PaperMC/paperweight-examples development by creating an account on GitHub.
I see the PR supports running gradle with jdk25, is it wise/have you been building against jdk25 as well or should that stay 21 until mc26 comes out?
it doesn’t matter as the toolchain uses java 21
it automatically downloads the jdk and builds using it so you won’t have issues
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
lmfaooo cyrillic friend 
Things seem to explode when trying to build against 25 so i'll avoid that for now
With this PR: https://github.com/PaperMC/Paper/pull/13538 Paper builds for me on java 25, when also paired with new version of Spark it runs too (not needed if you just want userdev I think)
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
Anyone know how my changes here wound up pulling in some other patch (EAR) for its fixes? It's been a long while since i've done a main paper pr: https://github.com/PaperMC/Paper/compare/main...Cryptite:Paper:entitydespawntime?expand=1
I mean, the EAR patch patches in an area that you changed in the source patches?
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
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
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
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
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
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
I think IntelliJ must've been just having a crisis then (see above screenshot from earlier), cause it shows up now
(fork question) how does one rebase and get the fork-server/minecraft-patches? rebasing in paper-server only shows the patches in paper-patches
What exactly is it that you are trying to do
edit a patch in fork-server/minecraft-patches
rebase -i base in paper-server only shows patches in the paper-patches folder
rebase in the minecraft git repo for mc patches
fork-server/src/minecraft/java
oh yeah, thanks
How can I adjust the indentation distance of the tree folder in intellijd? It takes up too much space on my screen
you'd probably want to enable the option called "use smaller indents" when you go to the tree view settings
ok thx y i will try it
@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 +rebuildPatchesmade.
(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?)
Yea they are leftovers
For feature vs source patches
Paper basically is a fork within itself if that makes sense.
so just no new comments on -api?
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
this being defined as paper-server/src/minecraft/java?
Files patches are basically one big feature patch by themselves, just split up 
E.g moonrise
Yea
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
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)
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)
but i had no intention to edit any existing file patches?
Which is wrong
You should have had that intention
Which is what I pointed out in the review
So my workflow should've been to find an existing patch that relatively impacted that area of change?
No
aka see if there's a --
Fixup your changes into the per file patches
I do not understand that statement
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
You don't have to no
The gradle bit automatically does the commit and fixup
As said, it will error in your case
ok let me try it all over again then
Because a feature patch after that will no longer apply
https://github.com/PaperMC/Paper/pull/13552/changes#r2695498831 also i was just maintaining code consistency here. Was the comment just to decrease patch noise?
It doesn't really matter if the field is public, as it is an internal class anyways, so yeah, decreases the diff a bit
Also by what lynx means is to just make a per file patch out of it
@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
appreciate that but i've had success in the past using IJ's resolve conflicts
which i am doing now, although admittedly i am thrown for this one
I can guarantee you that you will have a hard time here
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
Don't wanna discourage you from trying it yourself though, since doing that is the best way to learn
I mean i've been doing a fork for years so it's not my first paper fixup
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
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```
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?
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
maybe it's IJ fuckery
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.
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?
This isn't something we are interested in maintaining
Understandable, i was just hoping that this could get accepted as its pretty non-invasive, just another option exposed in the user extension
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.
what does the full modal look like
modal? Like the project creator?
Gimme a sec, not sure if I can get this on one screenshot
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
as is it's a bit overwhelming with the amount of options and not much hierarchy in the advanced section
Fair, but that's why it's called advanced options. Version catalog could definitely go out, alongside the bootstrap/loader options
even just a spacer between each plugin's "section" could help I think
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
I'll look if I can get something like that in, I am not super familiar with the templates here
it's ok if it's above, but maybe do one of those warning texts saying "this will force enable blahblah"
Fair
Hm I don't think there are any separators in this template system
hm, couldmaybe just bold the "Use the ... Gradle plugin" text (also make them all "Use" or all "Include"
)
that would also give it visual hierarchy
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
also I would put gremlin at the bottom, it's the least commonly used

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
hmmm
how do you find gradle plugins in the minecraft development plugin? because it doesnt exist.
Of course it doesn't exist
, because that's a feature I am currently working on!
Maybe soon™
a
i have been trying to get paperweight working for the past 3 hours and i give up
and the template online doesnt build.
You should follow the steps from this embed below:
For the Gradle update step you might want to first comment out the userdev plugin so that your Gradle commands run
i was missing a lot of things
anyways uh
i bet it doesnt have documentation to use NMS correct?
Any type of Paper internals are generally undocumented, correct
It's hard to document ever-changing code
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?
Basically your fork-server/src/minecraft/java is just a glorified git repository. Adding patches to it is basically the same as just adding a commit into that repository. There are multiple ways you can achieve that (manually coping the changes, applying the diff via git apply, whatever), however it's up to you and it depends on the patch
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)\
Okay I am happy with this. Took me a bit too long to properly implement the inline version selector, but it works now.
So once again:
- The simplest
build.gradle.kts(everything ticked off) looks like this: https://pastes.dev/5j318x9uKD - The options as shown in the screenshot:
build.gradle.ktsandlibs.versions.toml(wtf no toml support in pastes.dev?) - And ticking all plugin options (without catalog) results in this
build.gradle.kts
Sounds and looks good? (CC: jmp)
Anything I've missed in the build scripts themselves?
Why Java library?
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)
is there a reason you override the resource factory defaults, that is for name, version and load properties
also, do you support gremlin on the spigot template too? Or are those just if using paper
-# sorry lets not get offtopic in here
I initially thought you were joking, but I am actually unsure anymore. No, I don't. Spigot doesn't have a plugin loader setup like that (I know they have the libraries section, but that's a completely separate story), so gremlin doesn't exactly work super well on Spigot, at least to my knowledge
It wasn’t a joke, you don’t need a plug-in loader to do runtime dependency resolution, Libby has done without for ages now. That being said, it was also the reason I asked since I doubt gremlin has runtime support for it even if one could technically make it work, thought there was something I was missing with it but I guess not
Back when I used gremlin on my Minestom project, I did it with a javaagent running before the actual main method, not sure how it'd work in a Spigot plugin, but honestly, to me, Spigot has such low priority, that I don't think it's worth looking into
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
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
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?
if thats a file patch just modify the code, run the fixup task and then rebuild
what about a feature patch?
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
ok, thx
paper’s contributing md explains this in detail; it might prove useful for other questions you might have in the future too
k
bump, and also would appreciate feedback on #377 feat: allow for specifying ATs for upstream sources
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
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.
you can try setting the oldPaperCommit property in the server project’s build file to the commit your fork was built against before the update
it will bring in some objects, hopefully decreasing conflicts
assuming you’re forking paper, if not, then set it to the latest paper commit for that version
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
most likely
just confirming, "the commit your fork was built against" should be the paper commit or my fork's commit
paper commit
I'm trying to use variables to retrieve data from gradle.properties for use in paper-plugin.yml, but I've already tried: ${}, “${}”, “$”, $, and it doesn't work. The build logic is all in Kotlin DSL.
https://i.imgur.com/e4mAtKr.png
https://i.imgur.com/yQS5lLt.png
https://i.imgur.com/pcjb8a3.png
It should be just $version and similar, but what exactly doesn't work? How does the processed file look like afterwards? (You can check that by looking into build/resources). Furthermore, you can simplify the version and description obtaining by just using project.version and project.description, no need for the property getter like that
Now I've seen in .build that it gives me the file, but I think the variables are broken in the game.
What exactly do you mean by broken? If you run /version ExamplePlugin, what does it look like?

Just run the clean task and then run build again
Doing so does not delete the build folder. I deleted it manually, and as soon as it recreates it, it gives me the one without the variables, i.e. this one.
it has do delete the build folder
I did it, but when I recreate it, it's always with the wrong file.
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
I tried, but nothing happened. I had Gradle 9.2.1, and now it has updated to 9.3.0 after running those commands. I don't know if it has anything to do with how I build, i.e., through this section:
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?
yeah don't do that, you need to run gradle to build, forget about that artifacts thing entirely, it does not run gradle
your original configuration looked fine otherwise
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
I think blossom can do that
blossom seems to be what i was looking for, thank you
btw this snippet is not entirely good as the project.version needs to be declared in its own val, and only then can you pass the version, otherwise CC fails
val version = project.version
and then expand version to the val
I don't know how to compile without using artifacts. If you don't mind, could you explain it better?
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.
you either run gradlew build on your terminal, or in intellij on the gradle tab/pane on the right side find and fire the build task
Yes, I managed to get everything working from there. Now everything works. I'd say I've learned some new things, lol.
if you're using the shadowjar plugin, it will produce the fatjar with the "all" classifier, that's the one with the shaded dependencies, the one without the "all" classifier is the slim jar with just your project classes and resources
Yes, I'm reading up a bit on how to get Shadowjar working, and I still need to understand what paperweight.userdev is. It's Mojang's mapping. Let's say that it's already a lot that it works to switch from Spigot to Paper, and it's taking me some time.
If you were using specialsource maven plug-in, it isn’t much different in principle
It is tooling that provides you with the deobfuscated server internals
For more information
No, I used to only use Spigot APIs in a project with Groovy Gradle, so I first migrated to Gradle Kotlin DSL, then from there I started migrating everything else with Paper APIs. So I studied everything I could from the well-written documentation to better understand it all, even though I still have doubts, but I think those are normal since everything is new.
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.
That’s still build tooling related, so it should be fine here
I hope that if something happens, I'll change channels, lol.
No, that's wrong. It gets evaluated during the mapOf already, so the CC works perfectly fine.
ah yeah you’re right, sorry, i thought it was in the expand block 
next time i shouldnt respond when its midnight 
I mean, if you are only using API and don't need access to internals, you don't need to add paperweight-userdev, you just need to depend on the api
Sorry for the late reply, thank you. Now I understand, if I'm not mistaken, it's the NMS paperweight-userdev
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
Generally, make sure that you're using the correct JDK version
it knows the packages exist, it's upset about the classes themselves
I don't understand...
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?
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.
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
I think updating the IDE version did the job, but it makes no sense that it just broke for not updating, no?
pretty common
older IJ versions often don't work properly with newer JDKs, hardly the first time
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
just run cleanAllPaperweightUserdevCaches to fix it for now
I could probably improve the logging when that happens
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
"the project"?
You should be able to commit patch files just fine, just make sure to do it in the correct git repo
you serious?
i am able to commit them fine, the problem is after committed them and tried to rebuild the patch files were removed
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
il take a second look at it
okay i reset the entire project and just copied all the exisiting patches in and commited them, seems to work now, probably fucked up something early on
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?
You would need to ask jetbrains, we don't control that
You would need to ask paper, they do control that
Can you elaborate on why you're saying cat is incorrect?
how do I update run-paper to use a newer paper build, mine i sstuck at 69
ah nvm I got it, I had to run clean paper cache
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!
just use kotlin dsl
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
yeahh i'll just do that :P
kotlin has been the gradle default for a while
is there a way i can append my own arguments that paperweight patcher gives git-am
what is your usecase?
Hey, I installed the latest paper upload, a 1.21.11 upload, on my Linux server..
But spear swapping is not working.. WHY?
Please use the #paper-help channel for questions related to Paper
Oh, you did, in that case, please don't cross-post 🙂
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 ------------⬏
You need to manually apply it and fix conflicts
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
can i include a discord username instead of url/email in a user agent for downloading jars from fill v3?
i dont see why not, you could add https://discord.com as the site
this should be fine karmuss (https://discord.com)
for example
I feel like discord accounts are more ephemeral than email addresses. But, hey, if you want to make it potentially harder to be contacted...
well i’d personally sooner read a discord dm than check my email lol
atleast the message will be read
my cicd probably will only download like 5 times per day is that fine?
5-10
Everything is okay until a bug shows up 😂
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
Yeah but a discord user name might change in the future. An email you probably have permanently
What if my email is a temp mail?
Actually, don't answer that, I forgot we are in #build-tooling-help, which is serious
I was about to ask if this is a serious question
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.
👍
Caused by: groovy.lang.MissingPropertyException: No such property: mode for class: org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator$StubbedFileCopyDetails
yikes
i assume it might be due to outdated shadow
update your shadow plugin to the new coordinates and latest version
8.1.1 is latest
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
try changing the classifier of the shadowJar task’s output
set it to -all or sum, it might just have issues with file names
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.
i feel like i'm being stupid now, i only want to use nms but maven just hates it from what i searched up
is there a reason you're using remapping, do you mean to post this plugin on spigot?
nope, i'm just reading off what the paper site said
i would suggest looking at the example plugin repo
wheres that
you don't need that unless you want the final jar to use spigot mappings
so you can safely remove the whole assemble block
for reference
yeah see i dont have build.gradle.kts
i just have build.gradle
i have deadass never used gradle before, always maven.
damn i never used maven
i hate it
it is really not that different, you are just much more experienced with maven than you are with gradle
yeah
Gradle has two DSLs you can use for your build scripts, the groovy DSL (what you are using) and the kotlin DSL
my brain is just gradle corrupted from writing tons of gradle plugins 
is it paramount i use kotlin dsl?
it is the gradle default however it doesn't really change anything
how do i switch on intellij?
you can keep using groovy DSL, you'll just find some syntactic differences when it comes to examples using Kotlin DSL
its easier to find ur way around but some people find groovy easier due to non typesafe syntax
i see
iirc just change the file extension
so how do i make the build.gradle work?
and adapt the script if it fails to compile
i feel like a rookie lmao
do u want the jar to be reobfuscated to work on spigot or not
if not you can basically remove all mentions of remap jar
nah just paper
it's just for my server, won't be posting it.
do people even use spigot jars nowadays?
well the two percent that use spigot do 
but anyway they’ll have to switch to mojmap for next release
i wish i could use nms safely on maven
you can delete this entire block
done
afaik there is a community maven plugin that allows you
but its not supported here if you decide to go down that route
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
https://github.com/Alvinn8/paper-nms-maven-plugin
ill just link it for reference
oh
ew 1.21.8
i need 1.21.10
you can change it but yh sticking to gradle is the best way
gradle magic 
that's just the artifacts from your other failed runs
😂
check the modified dates
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.
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
}
183 lines
(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)
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
since the error message includes purpur, you might wanna ask on their discord.
it's Pufferfish including Purpur
and i assume same error will happen in normal Pufferfish too for the Minecraft version im using
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.
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
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?
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
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
this seems to have something with paperweight
it is, the build tooling has changed a lot since then, project setup is a completely different story than then, especially for forks
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
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 errorCould not determine the dependencies of task ':filterSpigotExcludes'also happens in PaperSpigot 1.20,4 which is more recent version.
it is more recent than 1.18, but it is also pre-hard fork, which is when the tooling changed a lot
Do note that those versions are basically unsupported, as is windows for all intents and purposes
try a shorter build path
outside of that, you'd generally need to diagnose why it's failing yourself
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
I mean, you can't get a paper jar from buildtools
if i apply Paper patches in it
The most widely used, high performance Minecraft server that aims to fix gameplay and mechanics inconsistencies - PaperMC/Paper
i think i would have to exclude 0001-Setup-Gradle-project.patch
anyways is it legally ok to distribute PaperSpigot jar built from Spigot BuildTools if i apply Paper patches?
No
hmm than maybe i should only post the patches on GitHub?
hmm i think i figured out why 1.18.1 kept failed
i saw the original PaperSpigot repo
https://github.com/PaperMC/Paper/tree/30cb7d0407bfb01a3bc0cc2da1dc0af32dfae5a4
it has a folder called work but this suddenly became missing when i was fixing papermc.io/repo thing
finally fixed
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
paperweight does not support that
the expectation is that you don't break that stuff, like with basically every single other codebase out there
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
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
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?
Basically, yes
I see, that's sort of what I assumed haha. Thank you for the help!
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?
you mean into how paperweight works?
yeah
it isn't necessarily something you need to know in order to make your own fork if that's the line of thought
or is my only option to copy from other forks to figure things out?
By works I mean any options etc which I might not immediately realise exist
ideally you'd start by looking at the https://github.com/PaperMC/paperweight-examples repository and go off from that
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
is folia not an option on the hangar publish plugin?
folia support is just a tag you can select in the project's settings
ty
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 🤡
you need to commit the changes
iirc
is paperweight planned to change its minimum supported version of gradle to 9.4.0?
i’d greatly appreciate if that’s the case
does something not work on that version of gradle? what's stopping you from using it?
it's mainly as i want to take advantages of new features in that release such as lazy configuration extending in my paperweight-related gradle plugin and i don't want to break users' expectation of maintaining minimum gradle version compatibility with paperweight
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
elo
gradle 9.4.0 was released just today, paperweight will likely update in due time however I doubt it is a priority
besides, it didn't really introduce anything mission-critical? Only thing of note is the java 26 support
not mission critical but the new progress bars are cool
yes!! i already tried! but it just happen nothing
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.
For that you'd use single file patches. There are gradle tasks to rebuild (rebuildSingleFilePatches) and apply them (applySingleFilePatches). There's an example here: https://github.com/PaperMC/paperweight-examples
Oh my... I'm a complete idiot.
Thank you so much! This has been driving me nuts for hours.
How do I make a project with multiple server software plugins while in the same folder and same gradle project
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?
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 @@
That will create a rejected patch, look at the lines that were rejected and reapply that
Then rebuild the patches
yea, changing userdev version from SNAPSHOT to beta.19 helped...
gotcha thanks
you shouldn't use the snapshot unless you have a specific reason to
why are the Minecraft java classes are orange, and nothing appears to change for git?
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
intellij shows me all the file changes in project
IntelliJ lies, the only truth is git cli
Im really used to intellij, so, is there a fix for this?
you could try adding other git roots but like, who has time for broken git frontends
just learn the actual tool
Fwiw the paperweight setup is validated to work using intellijs git UI
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
<@&748618676189528155>
(handled)
someone knows if there's an alternative for disablePluginJarDetection() on run-task paper?
I'm trying to obfuscate my code and I want to test the obfuscated JAR file without creating another server
alternative in what way?
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)
then you'd use that, and add the output jar manually to the pluginJars file collection
something like
runPaper {
disable...()
}
tasks.runServer {
pluginJars(obfTask)
}
that method definitely exists
so something like this?
yes
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
https://github.com/PaperMC/mache or look through https://mcsrc.dev/
tysm i forgor mache existed
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")
}```
Can you try setting the version to "2.0.0-beta.19" instead?
looks like it helped
it doing something
yes that works
tysm
np
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.
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 
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
Luckily 26.1 updated to 25 so you should be able to use jdk 25 just fine in the future
I mean, the asm lib might support that, decompiling existing versions with 25, will not
There's a section on it on the docs even
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?
The fix is to not use modules
Plugin dev is simply not module-ready
That was the conclusion I'd sadly kinda worked out
-# The more solution-y variant would be to compileOnly-depend on a brigadier variant which has a module-info.java https://github.com/Strokkur424/brigadier
Bit annoying, I wanted to use modules so i could have a sealed interface with impls across packages
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
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
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
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?
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
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
yeah exactly what i was thinking
you're right, you could probably just use the fork-of-a-fork setup in paperweight-examples to override the paper your folia fork is based off
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
would pinging him be a right thing to do? I always have the feeling nobody ever sees this channel
No, don't ping staff for questions like this.
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
I prolly have to make my fork public on github then, right?
you don't have to, repo just has to point to a valid git repository, that can be a local one if you want
but how would I authorize myself then? or is it just using my stored git credentials?
oh so you mean using a private github repo, no idea how you would go about that tbh. Not sure if paperweight supports inputting credentials given that it just runs the git commands and silently fails otherwise
I was thinking you were trying to use your local git repo for it
I just found out that it just works. I think it is just using my stored git credentials to authorize on github
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
what does your build script look like? I feel like it should work if you're doing it similarly to the v2-fork-of-fork branch
message.txt by @winter glacier: https://pastes.dev/k7ouSjNRFV
its exactly the one of the v2-fork-of-fork branch just with my names replaced
just to be sure, shulker is your paper fork right? Because if that's the case then I think we got a little confused
yeah shulker is my paper fork
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
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?
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
but what did you mean with this?
would folia be forky in that case?
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
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
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
Ahh okay that would work too I guess
I would appreciate it very much if you are also trying to set it up!
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.
<@&748618676189528155>
354 lines
Looks like compilation is failing because paper isn't in your dependencies
How do I update paperweight-userdev
Could not resolve io.papermc.paperweight:paperweight-userdev:2.0.0-beta.19
@trail pilot ^^
dev/26.1 is the branch yes
with the increadible obvious note that we haven't published paper as alpha for a reason
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?
nevermind, i wait... xD
does someone know why there is no 3.5.0-SNAPSHOT under https://fill.papermc.io/v2/projects/velocity ?
that is indeed the case
ty
@final jewel sorry for pinging, but did you find anything out yet?
no, I gave it a go but gave up on the end as I couldn't understand why the setup wasn't working exactly lol. Something always goes wrong when applying the patches
I couldn't fix it either. I gave claude code a try and it said that I should change the naming of the applyUpstream task in paperweight to a one that adapts to the name of the upstream, so apply{upstreamname]Upstream, so it can take multiple upstreams. I couldn't publish paperweight then, so I gave up too
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
Please ask this question in #paper-help
How do I build Folia now? What are the commands? ./gradlew build and all ?
just like Paper, see the paper readme
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
try using 2.0.0-SNAPSHOT, hopefully that has a userdev version deployed aswell
I did, that unfortunately did not work
oh right you said that
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
can you get a log when using that version and using --stacktrace
Sure
Caused by: java.lang.IllegalStateException: No such download 'server_mappings' in version manifest
looks like that part was missed during the update
Well, I am sure jmp will fix it in due time
I will postpone my plugin update until then though
my bad, i saw the 26.1 commit touched parts of the userdev folder so figured it might've been included
Alright, fair, thanks for the clear up
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?
idk
maybe bad gradle caches somewhere
thats before it runs the paperweight pipeline
Well, deleting the .gradle folder did nothing at all
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
im trying to use paperweight with 1.21.11, but gradle is throwing this error: https://pastes.dev/YxvIud73fj
already did that, gradle on version 9.4.0, its the latest version of userdev and already readed the docs
you are currently using 8.8 in that paste
ok, compiled it using my terminal and worked fine... Seems like intellij has a bundled version of the gradle thats outdated (now i need to figure out how to make it use the OS version). Thanks for the attention!
see build, execution, deployment -> build tools -> gradle, there's a gradle distribution option there
in the settings
ye, doing that rn, thanks
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
26.1 is not complete.
There's lots of stuff still being worked on.
im just saying that its outdated in case someone missed it
as the updating minecraft property has been disabled
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"
these seem to be missing
known
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
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
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
thanks
beta 21 building now
Nice, thank you
appreciate it
Finally I can build my plugins with 26.1.1 support in my pipieline 😄
keep getting this but idk where id be using reobf?
tried adding those paperweight blocks to see but same thing
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
not sure where id be doing so since its not found anywhere in my code
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 
what paperweight version is the correct when forking paper on 26.1?
the beta.21 works fine btw
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:
you may want to take a look at the multi-project branch of the paperweight-test-plugin repository: https://github.com/PaperMC/paperweight-test-plugin/tree/multi-project
this test plugin just uses "paperweight-mappings-namespace" with "mojang", which would not work in my case to support spigot + paper servers for 1.20.x to 1.21.11 where we need remap
nothing prevents you from having the same setup but with the spigot mappings, just a bit awkward given that remapping has been dropped for 26.1
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
I was already thinking about having a remapped and a non-remapped folder for these versions and then using "paperweight-mappings-namespace": "mojang" so that paper doesn't touch anything. But that bloats the plugin quite a bit.
I was thinking you could maybe have a gradle module whose only purpose would be to generate a remapped artifact out of the supported modules (that would be 1.16.x up to 1.21.11), however I am not quite sure how that setup would look like
I would just need a setting to tell paper: "please do not remap this one folder inside my jar" 😅
that just isn't possible unless you were to fork Paper, because older versions aren't being changed anyway
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.
though I guess you could take a look at source remapping, there's a branch in the paperweight test repo that does it
welp, there goes one option lol


