build-tooling-help

[smoky violet]

you definitely can selectively remap stuff by being selective with what you pass to remapjar and doing your own merging

[ornate prawn]

Could you not just change the compile target version? Or is that not a great thing to do in Gradle?

[smoky violet]

thats basically what the linked example is doing

[ornate prawn]

My bad, then

[smoky violet]

I was following up to myself not replying

you don't even need to use extra subprojects can use sourcesets and or custom task configurations

but userdev only supports one mc target per project

[glossy fox]

so this wouldn't work here, if i read your text correctly

[smoky violet]

I think most of the responses so far have been nonsequitors and have just muddied things, looking at your original message you just need asm updated in paper

I think we will update it for 1.21.11 if someone opens an issue

if you need older, you can just build with older java and use disableAutoTargetJvm

[glossy fox]

in GSit there isn't that much of nms, but there are other plugins of mine, which suffer from the same problem.

GSit has up to ~27k servers running it, with a good amount of them running "old" server versions, which still use the latest plugin versions. So dropping support for older versions sadly isn't an option for me even tough i would love to only support the latest x versions

[turbid moon]

On the Paper repo? I could just open one rq

[smoky violet]

its just bumping versions in the kts files so a PR would be better

but yeah

actually 1.21.11 is kind of in limbo since kenny created the branch for it before 26 is merged

not sure if you should target main or the .11 branch rn

[turbid moon]

Does the .11 branch still push out releases?

Because then I'd go with .11

[smoky violet]

yeah I think main is paused and .11 is building just need to make sure when we merge main we also merge from .11

[glossy fox]

it could do this in my 26.1 subproject like this, which compiles and would (i guess) solve the issue for now, but i would have to compile each never version 26.2, 26.3, 26.4 ... all to java 21 for this to work for the range of 1.20.x to 1.21.11 servers which use paper remapping

[smoky violet]

no, it also happens on servers without paper remapping, since plugin bytecode is still rewritten using asm by commodore

not being able to use newer java is in fact a constraint when you choose to support old versions in the same jar

[glossy fox]

the new version code is not loaded on older servers if there isn't the paper remapper, this isn't a issue if there is newer java code in my plugin

[smoky violet]

are you asking for help with your build or implying there's an issue here? because there isn't really anything for us to do other than update asm in 1.21.11 which is still supported

[turbid moon]

I cannot get a test plugin with userdev on 1.21.11 to even compile on Java 25. Why is my computer fighting me, it literally works for a different project of mine

[glossy fox]

the issue would still persist in older version like paper 1.21.4 which already uses the remapper. so a update to the paper code isn't a option i guess.
I hoped for a plugin-side solution to fix this issue on my side ^^

[smoky violet]

the tiny remapper fat jar might not support 25 if you have remapping on in gradle

[turbid moon]

Yeah, precisely

Yeah I forgot that I don't use the remapper on my other project ()

Urgh, time for multimodule test plugin

[smoky violet]

you could use nested jars and load them at runtime with hacks or paper classloader api

but it's really just not worth it

best options are use disableAutoTargetJvm, drop old versions, or start shipping 2 jars

[glossy fox]

I guess I'll stick with this option to use java 21 as a release target for 26.1, 26.2, ... for now until there is a blocker feature which can't be down-compiled to java 21 in a future update

Until this blocker feature is present I hope as much server owners as possible upgraded to a modern paper version ^^

[smoky violet]

I've had a total of 1 or 2 people ask about download the right minimotd jar

everyone else figures it out from the modrinth picker or the startup logs

started shipping 2 jars 7 months ago

[final jewel]

modrinth does make it easy to not select the wrong jar for a given version/platform

[glossy fox]

@smoky violet So you would suggest to split server version support? I don't know how many of this 27k sever owners can figure this out correctly, you can't trust the end user 😬

[final jewel]

I'd argue you can trust them to fail at it once, they'll figure it out after the first time

[smoky violet]

most of the people on old versions won't update anyway like mbax said

people mostly update plugins when they break or they update mc

[glossy fox]

I'm currently only using spigot & paper's hanger platform to distribute my plugins, but I'll probably add modrinth in the future to this list

[smoky violet]

modrinth can also buy you a couple beers (or energy drinks if you're underage) each month

[glossy fox]

~75% of server owners use a recent version of my plugin, while ~50% of servers use a old server version, so that's slightly different in my case

[final jewel]

^ they have an ad-revenue system in place that works pretty well for plugins/mods with many views, I'd expect Gsit to be one of those

[glossy fox]

I don't drink either of them

[smoky violet]

for context the split I did in minimotd was 1 jar: spigot/paper 1.8->1.21.7, and 1 jar: only paper 1.21.8+

[turbid moon]

Why does 26_1_mod also run reobfJar? I only have the dependsOn in the 1_21_11 module's build script

God I just want something I want to test my two line changes with

[smoky violet]

it's simple enough don't really need to test

[turbid moon]

Okay sure

I will just trust your judgment

[smoky violet]

on it's own that script looks fine

so it has to be somewhere else in the build, idk

[turbid moon]

, I can send you all the build scripts in a sec, because I am curious now

Also: https://github.com/PaperMC/Paper/pull/13743

[smoky violet]

well just compare to the multiproject example

[turbid moon]

But does that have a configuration where one does reobfJar and another submodule doesn't?

Gimme a sec to check

[glossy fox]

The thing you mentioned sounded quite interesting, but it wouldn't work with my setup, would it?
Currently, the plugin takes quite a long time to build in, for example, jitpack cd where there is nothing cached, because it downloads & builds nearly 20 paperweight versions

[smoky violet]

yeah it doesn't reobf latest

[smoky violet]

I misunderstood the problem at first and was talking about semi unrelated stuff

[glossy fox]

Ah, sad. I still hope that I can streamline my project setup a bit, but so far I haven't really found a way to do it. 😅

[smoky violet]

older versions prob take the bulk of the time

unless jitpack doesn't set the CI env var

when CI=true, modern versions just apply a paperclip. old ones (like <=1.17 or smth) have to decompile

should just use github actions though

and if you really don't want to host a repo you could use https://github.com/PaperMC/packages-maven-mirror and github packages like paper does for PRs

(would need a bit of tweaking)

[turbid moon]

I am sorry to say that I sadly am not able to find it. Eh it doesn't matter, I have no intention of ever using reobfuscation, even less now that it's dropped anyways

[smoky violet]

@turbid moon did you check the -api build kts

I think it might be in there too

(for runtime server will win but we dont want outdated deps in consumer builds)

[turbid moon]

I have a feeling I am checking the wrong project

[smoky violet]

paper-api and paper-server

[turbid moon]

I am on the multi-project branch of the paperweight-test-plugin repo

Oh you are talking about the other stuff

Sec

[turbid moon]

Yeah it's there

[smoky violet]

at the end, it's not using reobfJar

[turbid moon]

Okay that should be all of them

Why doesn't Paper use Gradle version catalog

[smoky violet]

the example doesn't dependsOn reobfJar anywhere; those reobf deps create implicit dependencies when the main proj builds

[smoky violet]

because we are friendly to forks

[turbid moon]

Oh, yeah, true, didn't think of that

Or just single file patch for version catalog file

[smoky violet]

it would create an additional chicken-egg problem for them

[turbid moon]

(not feasible I am guessing, since it's not a project file in the direct sense)

[smoky violet]

additional because you know, we already have the nested gradle invocations to make applyAll work

the main thing is if we use the same hacks it will cause ALL task outputs to get invalidated by the toml updating

complicated problem

I've had at least two attempts to cleanly use catalogs for paper

[turbid moon]

I am incredibly thankful to you for paperweight, doing literally anything with Paper internal code/source code would be an incredible pain otherwise

[turbid moon]

Well, good to know that some thought went into and it isn't implemented due to technical problems/limitations, not because it was simply forgotten

[turbid moon]

But yeah, I am positive it is

[smoky violet]

👍

[turbid moon]

Also I just based the version off of what was in the 26.1 branch

I hope that's right

[smoky violet]

was just gonna ask if 26.1 needs it too

merged

[turbid moon]

Great

Fastest ever Paper PR I had merged

[kindred geyser]

I had the same issue btw

[turbid moon]

Well, in case you are curious about the exact project setup where I did reobf for 1.21.11 and no reobf for 26.1 but it still attempted it, have a test project zip, but I don't thinjk it matters

[smoky violet]

use a build scan to find out whats triggering the task

[turbid moon]

That's also a suggestion I guess

[smoky violet]

(to both of you )

[turbid moon]

Also wtf why does my terminal icon always move when I restart IJ

On paper it's on the right side, on the untitled it's on the left side

[smoky violet]

cooked

[turbid moon]

Truly

Soo, how do I see what ran the task now in the scan

[smoky violet]

send the activated scan link

[turbid moon]

https://scans.gradle.com/s/ggcwivig47ose

[smoky violet]

in timeline

the root project is consuming it somehow and those tasks need it

[turbid moon]

root doesn't even have paperweight as a plugin

This is the root build.gradle.kts https://pastes.dev/9mcpzbzmBv

[smoky violet]

run the outgoingVariants task on the 261 proj

seems like maybe it's defaulting to the reobf variant?

[turbid moon]

https://pastes.dev/Zto1GEsLDU

[smoky violet]

maybe because its technically a closer match when java 21 != java 25

actually no that doesn't make sense, the normal variant would also have that mismatch

oh the reobf variant doesn't declare a jvm attribute, that might be why

[turbid moon]

Is that something faulty in paperweight or in the way my submodule is setup?

[magic hearth]

I downloaded this and did :26_1_mod:build and it worked fine

[turbid moon]

The individual build is fine, yes

[smoky violet]

yeah try the root build

[turbid moon]

It's only when you build the whole project

[magic hearth]

thats weird

[turbid moon]

Yep

[smoky violet]

it's because on the apiElements or runtimeElements the jvm attribute is a mismatch, 21 vs 25, and the reobf doesn't have a jvm ver

so it technically has less of a difference from the consumer and becomes the default

latest paperweight snapshot might fix it

still building

[turbid moon]

The snapshot seems to have broken it hard @smoky violet https://pastes.dev/LpsztAe5Td

[smoky violet]

i think that’s right actually

u need disaableAutoTargetJvm

in root

@turbid moon

[turbid moon]

Lemme try

Oh yeah, that builds

Now lemme check if the classes are correctly mapped in the jar

They seem to be both Mojang mapped

Well, 26 anyways, but 1.21.11 is mojang mapped regardless

But that might just be because I am not including the reobf classes

Lemme figure this out

Oh yeah very nice

Now, time to check if it works on latest 1.21.11 and if it broke on non-latest 1.21.11

Fuck yeah

I love when stuff works

Also works when running Java 21 interestingly enough

[open latch]

for the toolchain not?

[turbid moon]

Well yes, but the server is ran using Java 21 and the Java 25-compiled 26.1 module still remaps correctly

Which is fine, since when you are running Java 21, you should never have 26.1 code be invoked, which is therefore fine if it is Java 25 compiled

[open latch]

its not for this?
https://github.com/PaperMC/Paper/pull/13739#discussion_r3034609153

or im very lost in gradle xd

[turbid moon]

I am talking about something different

[open latch]

then im lost sorry xd

[turbid moon]

[high compass]

I'm currently trying to make a fork of paper where the hitboxes are reverted back to the 1.12 hitboxes for use with viabackwards so my server backend is completely up to date but the frontend still uses 1.12, and I used to do so with paperweight-examples via:

1. Cloning the repo
2. Changing the instances of "forktest" to my fork name (and the group IDs from com.example to dev.meluhdy)
3. Running applyServerPatches
4. Making changes in the server folder
5. Committing the changes and running rebuildPatches to generate the patch files
6. Pushing to my github repo

But the issue is that doesn't seem to work on the v2-fork branch of paperweight-examples, as there doesn't seem to be any subrepos anymore for me to commit to to generate the patches. Is the workflow different now?

[lament scarab]

There are like 2 git submodules inside of the minecraft sources tree

one for resources, one for the actual mojang code

[high compass]

Ohh okay it was nestled a bit deeper than I think it was last time, solved

[stable aspen]

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).

dev bundle not usable now?

nvm

[teal cloud]

> Task :prepareKotlinBuildScriptModel UP-TO-DATE
Could not resolve: net.essentialsx.essentialsx:2.21.2
Could not resolve: com.squareup.moshi.moshi:1.15.2
Could not resolve: com.zaxxer.hikaricp:7.0.2
Could not resolve: com.github.instantlymoist.privatebin.java.api:master-5625a57693-1
Could not resolve: me.clip.placeholderapi:2.12.2
Could not resolve: com.github.cryptomorin.xseries.fork:13.6.0
Could not resolve: net.wesjd.anvilgui:1.10.11-SNAPSHOT
Could not resolve: net.byteflux.libby.bukkit:1.3.1
Could not resolve: dev.faststats.metrics.bukkit:0.18.1

BUILD SUCCESSFUL in 273ms

Why can't it find the dependencies

I'm trying to upgrade an old maven build to gradle

Build File:

[brave widget]

build.gradle by @teal cloud: https://pastes.dev/GxAOcgliFz

[teal cloud]

It's so mixed between Kotlin and Groovy

[teal cloud]

What's better than the problem evolving

6:18:50 μ.μ.: Executing 'shadowJar'…

Calculating task graph as no cached configuration is available for tasks: shadowJar
Configuration cache entry stored.

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':shadowJar'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
   > Could not find net.wesjd.anvilgui:1.10.11-SNAPSHOT:.
     Required by:
         root project 'EssentialsX-GUI'
   > Could not find net.byteflux.libby.bukkit:1.3.1:.
     Required by:
         root project 'EssentialsX-GUI'
   > Could not find dev.faststats.metrics.bukkit:0.18.1:.
     Required by:
         root project 'EssentialsX-GUI'

* 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 79ms
6:18:50 μ.μ.: Execution finished 'shadowJar'.

[lament scarab]

generally, run with the debug flag and see if it tells you why it's failing to pull that stuff from the expected repos

[teal cloud]

Should I be worried for these parts of the code that I will miss something important
https://mclo.gs/LApbpzX

And why is it like this:
EssentialsX-GUI (${project.version})

[dusk quail]

all of your dependencies are artifact ids only, the only one with a groupid is paper api

[teal cloud]

I fixed it

I used a scuffed maven 2 gradle depend that does half the job and fixed it

[final jewel]

if you had a pom.xml, gradle should automatically convert it to a build.gradle.kts by running gradle init on the project

[teal cloud]

Does half the job

It was a good starting point

[final jewel]

did it not pass all dependencies? That's interesting

[teal cloud]

It uses api instead of implement

[final jewel]

ah, that might be a thing because of the difference between scopes in gradle and maven

[teal cloud]

I've finished it anyways but I still don't know why the version placeholder doesn't work

[final jewel]

what would the version placeholder be

[teal cloud]

${project.version}

[final jewel]

can you show your build.gradle.kts?

[teal cloud]

I have some problems lol

Is this enough
https://mclo.gs/7N25K3j

[grizzled river]

does paperweight beta-2.0.0.21 require java 25?

[turbid moon]

I don't think paperweight has a Java version requirement, to my knowledge only the dev bundle has. 26.1.1 requires Java 25, yes. 1.21.x uses Java 21

Why are you asking? Did you encounter any issues?

[mossy mesa]

I'm having java version issues as well

Execution of 'net.fabricmc.tinyremapper.Main' failed with exit code 1. Log file:

id "io.papermc.paperweight.userdev" version "2.0.0-beta.21"
paperweight.paperDevBundle("1.21.11-R0.1-SNAPSHOT")

[grizzled river]

Nah, just curious. Thanks for the answer

[bronze ember]

The version of tinyremapper you are using doesn't support java 25

[bronze ember]

It def has a version requirement, whatever it was compiled with (or well, to)

[mossy mesa]

how can I get around this

just updating to 26.1 paperweight?

[lament scarab]

See the pins

[mossy mesa]

thanks!

[dusty canopy]

• Something that must have changed with the shadow gradle plugin. I will provide build file

https://gist.github.com/Thorinwasher/94a7e5440cd1b35b74fd835970ad4a57

[dusty canopy]

Okay, I think I found something. The new shadowjar artefact provides something new in META-INF/versions/9 directory, which is specific to exactly snakeyaml by some reason

[lament scarab]

Well, that would be the multiversion jar stuff

shadow just copies those classes from the snake jar

idk if it properly applies relocations to that stuff, I would hope so, but if it failed to do so, that would be your issue

[dusty canopy]

Ah it doesn't look like it, no

I barely know how it's meant to function though

[final jewel]

that was a bug with shadow at some point but it was fixed ages ago

[dusty canopy]

Well, I'm on 9.4.1 so 🤷‍♂️

[final jewel]

https://github.com/GradleUp/shadow/issues/525

I just checked the code around that and it seems to be the same, so the issue might stem from elsewhere

[final jewel]

what happens if you downgrade? Does it work?

[dusty canopy]

yep

So it must have been reintroduced then

[final jewel]

now that I look at it, 9.4.1 did move some code around that was used for MRJARs: https://github.com/GradleUp/shadow/commit/49f8c31185a0dad91d9ae2cb04bb6d2820717667#diff-30412e787fb923fca0e5d972da22e9c62662d9a45b049b53d58af489debf0f9dL45-L58

so maybe they accidentally reintroduced that bug yeah

[dusty canopy]

Yep, I'm interested in what has changed though, having a hard time finding actuall differences between the two artifacts (9.4.1 vs 8.2.9)

[final jewel]

https://github.com/GradleUp/shadow/pull/1972 maybe AI's fault? Lol

nevermind, that change shouldn't affect anything unless I am missing something there

[final jewel]

okay, I think I understand the issue now

you're relocating both simpleyaml and snakeyaml

if you remove the relocation to snakeyaml, it might just work I believe

[dusty canopy]

I'm not even sure if I need to provide those artifacts, anyhow just interesting issue

[dusty canopy]

Okay, the issue seems to be that multirelease is set to true on the new one, which aires this issue. It's not present in the old shadow compile versino

[lost falcon]

im not sure if it has been asked here before, but how do i set up the paperweight-patcher plugin with 1.21.1?

paperweight {
    serverProject.set(project("testing-server"))
    remapRepo.set(paperMavenPublicUrl)
    decompileRepo.set(paperMavenPublicUrl)

    usePaperUpstream(providers.gradleProperty("paper_version")) {
        url.set("https://github.com/PaperMC/Paper-archive.git")
        ref.set("ver/1.21.1")

        withPaperPatcher {
            apiPatchDir.set(layout.projectDirectory.dir("paper-patches/api"))
            apiOutputDir.set(layout.projectDirectory.dir("testing-Paper-API"))
            serverPatchDir.set(layout.projectDirectory.dir("paper-patches/server"))
            serverOutputDir.set(layout.projectDirectory.dir("testing-Paper-Server"))
        }
}

this is in my build.gradle.kts but whenever i run it it spams an error

setting paperweight.debug to true does not give me any more info, current paperweight version is 1.7.7

i cannot for the life of me figure this out, i even tried to use the same configuration that folia 1.21.1 used

also, please do ping me on reply, thanks in advance

[lost falcon]

managed to fix it, had to downgrade gradle from 9* to 8.14.4

gradle 9 apparently does not like paperweight yet

[turbid moon]

Paperweight does like Gradle 9, but the old paperweight version simply doesn't

Paperweight 1.7.7 is really old by now

[lost falcon]

aha, that would explain that

[lost falcon]

true, but the newer versions expect some extra folders which are not present in 1.21.1

[torn sonnet]

So is 1.21.1

[turbid moon]

Indeed

[lost falcon]

better than 1.20.1 atleast ¯_(ツ)_/¯

:p

[turbid moon]

Do you know what's even better? 1.21.11!

And then you can use Gradle 9.4.1 and the latest paperweight

Everyone wins!!

[lost falcon]

cant argue with that logic

[torn sonnet]

I wouldn't want to deal with the exploits on outdated MC. But good luck!

[lost falcon]

oh yea old as hell deps are always fun

well for future reference, since everything moved to the archive youd need to do:

usePaperUpstream(providers.gradleProperty("paperRef")) {
        url.set(github("PaperMC", "Paper-archive"))
        ref.set("ver/1.21.1")

[lament scarab]

I think that the expectation is that you generally use commit hashes given that they're stable rather than using a branch name

[lost falcon]

quick question, does using paperweight-patcher version 2+ break compat for older versions or can i just build it with that?

[bronze ember]

its generally not something we care deeply about, but there is code that should allow that

wait patcher? not too sure about that, userdev supports older dev bundles

patcher v2 might require mache

[lament scarab]

userdev does because can't multiversion and we sorta have to be nice there

patcher I don't think gets the same treatment, the build process changes a whole lot more than the plugin dev side of stuff and. doubt anybody would want to maintain the chains thereI

[lost falcon]

hm interesting, could try but cant be bothered with another couple hours of trying to get that to work

ill stick to 1.7.7, thanks for the info though

[turbid moon]

So, I have a Paper fork with the same structure as the paperweight-examples project. I would like to publish a dev bundle alongside an API artifact. Simply running publishToMavenLocal only published the API. I already found the generateDevelopmentBundle task, I simply am uncertain how I can actually publish it to a Maven repo.

[lucid mulch]

you need to pass the -PpublishDevelopmentBundle arg to the console while running the publish task

or -PpublishDevBundle

the name is somewhere in the server build file

[lucid mulch]

its this one

[turbid moon]

Ah great, thanks

[harsh ore]

Heya, when using gremlin with JDA I am getting ClassNotFoundExceptions.
any idea what might be causing that?

https://pastes.dev/E5EDVS1gBH

https://pastes.dev/izihYpLppt

[brave widget]

unify-dependencies.txt by @harsh ore: https://pastes.dev/ZOi31R6iYu

[harsh ore]

Different error now on different project suddenly appeared:
https://pastes.dev/4HslTk8wnX

build.gradle.kts has same gremlin settings, just the dependencies are different:

    compileOnly(libs.paper)
    compileOnly(libs.humanoid.api)
    runtimeDownload(libs.kotlinx.json)
    runtimeDownload(libs.stdlib)
    runtimeDownload(libs.triumph.polaris)
    runtimeDownload(libs.triumph.cmds)
    runtimeDownload(libs.triumph.gui.paper)
    runtimeDownload(libs.humanoid.platform)```

[lament scarab]

Well, sounds like that plugin expects to be inside of the plugin classloader rather than the libraries one

[harsh ore]

Can you rephrase? not entirely sure I get what you mean

[lament scarab]

Caused by: java.lang.IllegalArgumentException: class dev.triumphteam.gui.guis.BaseGui is not provided by a interface io.papermc.paper.plugin.provider.classloader.ConfiguredPluginClassLoader

it's upset because it's not accessing a specific classloader

either you shade it or you see if there is a way to give it what it wants

[harsh ore]

any way to figure out what it wants?
never had problems with gremlin until these 2 libraries.
not entirely sure what is different about them compared to others?

[lament scarab]

We can't really provide support for random software on the internet

either it provides a constructor which lets you pass in the plugin instance or classloader or something, or you'll just need to shade it

[harsh ore]

I will ask the dev to see if there is a way.
is it the same story for JDA?

[lament scarab]

That one more looks like you're missing a transitive dependency

[harsh ore]

I thought gremlin manages those? and the dependencies file contains the libraries it claims it can't find

[lament scarab]

Well, it failed to find the kotlin coroutine class

[harsh ore]

What I find interesting tho is that locally when using run paper the JDA works fine, I don't get those errors.
but once I put it on the actual server I get those weird issues.

[median pulsar]

Is there a paperweight fork gradle task that only checks if the server compiles without actually bundling the jar?

[lament scarab]

just run the compile tasks?

[median pulsar]

yeah

after changing fork-server/build.gradle.kts what am I supposed to run to generate a patch for it?

[lucid mulch]

read the output of ./gradlew tasks

its the single file patches task

[grim mauve]

I think I'm stupid but I have no idea why my project is throwing after updating to 26.1.2 when building

The current dev bundle does not provide reobf mappings.

I get why the error exists (bundle does not have the Spigot mappings) but I'm not using Spigot mappings , this happens every time I use ./gradlew build because something runs the ./gradlew reobfJar task (this is a project with multiple submodules (each submodule is a plugin))

[smoky violet]

I think thats the one fixed by https://github.com/PaperMC/paperweight/commit/ac8614f774c772f98e97aec7da6ec4dc19636c4c

[smoky violet]

^

try the snapshot

[lucid mulch]

are you sure u didnt set the spigot namespace anywhere or linked up the reobfJar task in ANY of your submodules’ gradle scripts

[grim mauve]

now it is throwing a different error

[grim mauve]

I'm 99% sure

all of the plugins had paperweight.reobfArtifactConfiguration = io.papermc.paperweight.userdev.ReobfArtifactConfiguration.MOJANG_PRODUCTION (I removed it and didn't fix the issue)

[smoky violet]

yeah the bug was that it didn't throw an error before

your consumer is looking for J21 compatible and it was trying to consume a J25 project

you need disableAutoJvmTarget like strokkur did

[grim mauve]

maybe I'm stupid and haven't noticed this

I did update all of my submodules to use Java 25 but that specific module was cherry picked from my 1.21.11 branch

now it makes sense why everything borked out

changing it to Java 25 fixed the issue

thanks jmp!

[smoky violet]

btw thats the default in 2.x

[lucid mulch]

i recall the docs specifying the mojang namespace explicitly so this could be where they got it from

[grim mauve]

I have been using paperweight (since 1.3.1) for a long time already so I guess that's why it was still there

[lucid mulch]

https://docs.papermc.io/paper/dev/userdev/#compiling-to-mojang-mappings

[final jewel]

docs should probably be updated to remove the spigot mappings option altogether maybe

or just mention that it is a possibility for older versions, idk

[lucid mulch]

there is no mention of it being the automatic choice

[final jewel]

I mean, there is no spigot mappings anymore so that makes sense lol

[lucid mulch]

there wasnt one before too

this section is the same as it was pre 26.1

its kept for historical reasons

[turbid moon]

I am thinking that it might be worthwhile to add a entry to the userdev docs for this, because I assume more and more people will keep running into this

[turbid moon]

I mean

[smoky violet]

once I push a new beta to fix the lack of capabilities it's just standard gradle resolution rules

feels like scope creep but idk

[torn sonnet]

To follow up on strok's reply - I think it's worth keeping for a bit longer while we're still very much in alpha and 1.21.11 is still recent.

[final jewel]

fair enough

[teal solar]

considering you'll have people still interested in developing for older versions then i'd say it's better to keep it somewhere as archived for historical reasons

[teal solar]

okay yeah i hadn't read the whole chat yet my bad, but basically this

[sick bough]

it's that time of the year again where I forget how to properly update the server software because I did not write it down
anyways, I am trying to update (a fork of a fork, paper -> purpur) from 1.21.8 to 1.21.11. I did update the commit hash and what not, but I think I am running the wrong tasks to properly update it. What is the standard procedure to do so?

[fading vapor]

Why not just search for the old conversation?

[sick bough]

well, I did, turns out the conversation ended without a proper resolution, so that's that. and my way of fixing it was re-writing all the patches on a fresh fork, I was hoping to upgrade it properly this time lol

nevermind

[misty pond]

How enable preview features? When I use command gradlew createPaperclipJar I get errors:

             this.broadcastToViewers(viewers, chatType, _ -> renderedMessage);
                                                        ^
   (use --enable-preview to enable unnamed variables)
 19 errors```

[lament scarab]

I mean, if this is for a private fork then you should just be able to add it to the compile task

either through some direct jvm arg but i'd be surprised if there wasn't an option for it

[median pulsar]

when you get a conflict in fork-server/build.gradle.kts when running applyPaperSingleFilePatches how are u supposed to fix it? I don't see any git conflict marks in the file

[proud maple]

look for a build.gradle.kts.patch.rej file

[static urchin]

also try applySingleFilePatchesFuzzy first

[median pulsar]

TY

[lyric basalt]

Does anyone know why i am struggling with some imports on the latest paperweight version?
paperweight.paperDevBundle("26.1.2.build.+") using 2.0.0-beta.21

[torn sonnet]

My votes are:
a) Accidental java version mismatch and shenanigans with your IDE
b) IDE just being goofy.

With IDEA, I just hit the Repair IDE button and see what happens.

[lyric basalt]

It was a java version mismatch. Thanks mbax 🙂

[lyric basalt]

are the reobf mappings missing from the latest paperweight?

[torn sonnet]

There's no such thing on 26.1

[lyric basalt]

Oh interesting

so do i essentially just need to take out the reobf task

[main mica]

yep

[lyric basalt]

me trying to find where reobf is being referenced still even though it is nowhere in ctrl shift F

[torn sonnet]

Doing multiversion? I think you'll need to use paperweight 2.0.0-SNAPSHOT and add a disableAutoTargetJvm()

[lyric basalt]

Hm, 2.0.0-SNAPSHOT can't be found it seems

[torn sonnet]

pluginManagement {
    repositories {
        gradlePluginPortal()
        maven("https://repo.papermc.io/repository/maven-public/")
    }
}

[lyric basalt]

wew thank you, its working.

[stable aspen]

I'm using dev bundle, how can I make the version to be the latest automatically? I'm now using paperweight.paperDevBundle("$MINECRAFT_VERSION"+".build.7-alpha")

version is 26.1.2 here

[static urchin]

See the dev documentation

https://docs.papermc.io/paper/dev/project-setup/#adding-paper-as-a-dependency

[blazing venture]

is not abstract and does not override abstract method with Java 25 and Lombok (latest version)

No errors on IntelliJ only when run Maven package

With Java 21 works fine

I tried and this but is still same
https://projectlombok.org/setup/maven

[median pulsar]

What determines whether a commit is going to be a file patch or a feature patch?

I somehow managed to make my file patches into feature patches, and I don't know how to go back

[static urchin]

The commit tagged with file in the inner git repo is broken apart into the file patches

all commits on top of that commit are feature patches

[median pulsar]

thank you so much

[stable aspen]

> Task :paper-server:applySourcePatches
[WARN] Patching: net/minecraft/world/item/component/Consumable.java
[WARN]  Hunk 0: FAILURE: @@ -68,8 +68,13 @@

> Task :paper-server:applySourcePatches FAILED

Execution failed for task ':paper-server:applySourcePatches'.
> java.lang.Exception: Failed to apply 1/3062 hunks

* 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 11s
18 actionable tasks: 3 executed, 15 up-to-date
Configuration cache entry reused.

what does this mean when I applyPatches

[bronze ember]

that theres an issue with the patch

did you modify the patch?

[stable aspen]

don't think so

how to revert it then

[terse quail]

@fading vapor re: I unzipped it and only saw my own classes so I assumed the kotlin stdlib was missing.

[dusk quail]

just to double check, are you getting your jar from build/libs?

[fading vapor]

@terse quail are you running the gradle build task or IJ's buit in compiler

[terse quail]

Yep.

[terse quail]

I’ve been running gradle jar but, yeah, I think that’s what gradle build would produce?

Sorry if these are unhelpful answers. I’m really new to Gradle.

[turbid moon]

What you need is the output for gradle shadowJar

jar simply compiles your own classes into a jar file, shadowJar includes/shades library files, such as the Kotlin stdlib

In your build script you have ```kts
tasks.build {
dependsOn(tasks.shadowJar.get())
}

This means that whenever you run `gradle build`, it also runs `gradle shadowJar`. That's the reason why you typically are told to run `gradle build` instead of `gradle jar` directly

[terse quail]

Ohhh

Oops.

I see.

[turbid moon]

Yep

Also ensure that you are using the jar with the -all suffix, since that's the one generated by shadowJar

That's how you can generally distinguish the files

[terse quail]

Huh. I ran gradle build but it didn't do anything until I cleaned the build directory. iirc, that's why I started running gradle jar in the first place.

[fading vapor]

Run shadowJar directly

Then do as Strokkur said

[terse quail]

Okay. Running gradle shadowJar consistently rebuilds the project correctly.

Out of curiosity, is there a reason gradle build just doesn't rebuild things?

[lament scarab]

I mean, there is caching

it should of seen the fact that build runs extra stuff, however

[novel knoll]

it should work, if that's the whole build script then i don't necessarily see anything wrong with it other than calling .get() on tasks.shadowJar which ideally you'd omit calling

[terse quail]

But wouldn't those caches be invalidated if the input to the jar task on which build depends—the source code itself—changed? Or can the build task configure more specific conditions for reruns?

[lament scarab]

if the code changed then the cache should be invalid

[terse quail]

Huh. I guess it's doing it now???

[novel knoll]

build task doesn't really do anything on its own, it's a lifecycle task, lifecycle tasks run actionable tasks; jar and shadowJar for example are actionable tasks
it really comes down to what jar and shadowJar see, but build on its own should work as it's just running jar and shadowJar (provided the dependsOn) anyway

[terse quail]

It's odd. I remember calling gradle build and not seeing a shadowJar artifact, but then cleaning the build directory and rerunning it and seeing that artifact being built correctly.

But now it works perfectly.

I feel like I'm being gaslit. 😅

[novel knoll]

by yourself 🥸

[terse quail]

Anyways, thanks for all the help!!

[glacial lintel]

im using paperweight, is there any way of getting intellij's search feature to work with it? i.e i can search for minecraft intenal classes, but functions like 'find usages' dont work at all. im assuming intellij hasnt properly indexed the relevant classes?

[static urchin]

find usages iirc is reserved for actual source files no?

[novel knoll]

for find usages make sure to select "Project and Libraries", it defaults to Project only; as long as you have sources attached it should otherwise work

lynx that's find in files

find usages is when you hit mmb or ctrl b

and it brings up call sites and other references to the symbol

[static urchin]

but also in library files?

[glacial lintel]

thanks, that worked

[static urchin]

mysterious idea ways

[novel knoll]

yes, but you need to select "project and libraries" lol

[terse quail]

I'm getting a new error with shading for a velocity plugin...

[07:55:16 ERROR]: Exception in thread "Thread-2" java.lang.NoClassDefFoundError: it/unimi/dsi/fastutil/objects/ObjectArrays
[07:55:16 ERROR]:       at it.unimi.dsi.fastutil.ints.Int2ObjectArrayMap.<init>(Int2ObjectArrayMap.java:74)
[07:55:16 ERROR]:       at net.minestom.server.recipe.RecipeManager.<init>(RecipeManager.java:34)
[07:55:16 ERROR]:       at net.minestom.server.ServerProcessImpl.<init>(ServerProcessImpl.java:164)
[07:55:16 ERROR]:       at net.minestom.server.MinecraftServer.updateProcess(MinecraftServer.java:96)
[07:55:16 ERROR]:       at net.minestom.server.MinecraftServer.init(MinecraftServer.java:86)
[07:55:16 ERROR]:       at net.minestom.server.MinecraftServer.init(MinecraftServer.java:91)

(do not worry about why Velocity is running an embedded Minestom instance)
Weirdly enough, it.unimi.dsi.fastutil.ints.Int2ObjectArrayMap is resolved but it/unimi/dsi/fastutil/objects/ObjectArrays isn't? I unzipped the bundled jar and it seems to be there so I'm not exactly sure what's happening. The offending line is...

public Int2ObjectArrayMap() {
    this.key = IntArrays.EMPTY_ARRAY;
    this.value = ObjectArrays.EMPTY_ARRAY;  // <--- here
}

...which is odd because it means that IntArrays could be found but ObjectArrays couldn't?

[pliant carbon]

maybe something else is shipping a different version of fastutil, try relocating your shaded version so it doesn't conflict/use a different version provided by velocity/another plugin

[terse quail]

Oh huh. I just assumed shading would also perform relocations automatically.

[terse quail]

Okay, relocating the dependency fixed it. Thanks, again, for the help!

[stuck pilot]

For some reason updating to 26.1.2 using userdev caused this error

:platform-paper:main: Could not resolve io.papermc.paper:paper-api:26.1.2.build.24-alpha.
Required by:
    project ':platform-paper' > io.papermc.paper:dev-bundle:26.1.2.build.24-alpha```
I went from `paperweight.paperDevBundle("1.20.6-R0.1-SNAPSHOT")` which worked perfectly fine to `paperweight.paperDevBundle("26.1.2.build.+")` which immediately caused the error. What am I doing wrong?

Oh wait java version

[lucid mulch]

also this

[stuck pilot]

yeah no I forgot I needed to use java 25

[lucid mulch]

happens to the best of us

[lucid mulch]

i have ran into a roadblock with my paperweight pr and im hoping someone knowledgeable will be nice enough to jump in
https://github.com/PaperMC/paperweight/pull/377#issuecomment-4320833953

[harsh ore]

Has anyone gotten Gremlin and JDA to work without having to shade stuff into the jar file?
I am getting classNotFoundExceptions from okio

[smoky violet]

I would bet same thing happens if you used the maven resolver built in to paper - typically this is caused by classloader semantics

i.e. library loader is visible to plugin loader, but not the other way around unless you explicitly pass things over

or context class loader

share the actual error.

[harsh ore]

sorry for the late reply, for example here:
Gradle: https://pastes.dev/f1B3l8l8O7
Error: https://pastes.dev/6Ur77mH7Mq

[cobalt lotus]

I'm working on migrating an existing spigot plugin to paper, using paperweight-userdev for internals. The plugin is written for 1.21.4, and I would like to use 1.21.4 apis as I have been with spigot, but it seems that paperweight-userdev is forcing me to use the 1.21.8 api. A minor issue I'm having is Sound.ENTITY_WOLF_HOWL no longer exists in 1.21.8 but does on .4, how can I force it to use the older version of the api?

[torn sonnet]

Those are both weirdly outdated versions nobody's really using at this point. Are you certain you're not setting the wrong versions somewhere or pulling in a newer dep transitively?
-# I'd still just update to 1.21.11+

[cobalt lotus]

well it's for a single server that has a lot of interworking parts so upgrading the entire server is in the far future. I'm 99% sure it's not set to the wrong version somewhere, in my buildscript I have this set, and nowhere else:

dependencies {
...

paperweightDevelopmentBundle("io.papermc.paper:dev-bundle:1.21.4-R0.1-SNAPSHOT")
}

I also tried the other way with paperweight.paperDevBundle(...), same result, and I cleared caches in my user home and project files

might've fixed it lol, 1sec

Intellectualsites BOM was setting the dependency for me

removed that and it's fixed

[torn sonnet]

Called it! :3

[coarse ginkgo]

is paperweight open for PRs right now? asking to know if it even makes sense to create one cause I can see 10 long-open PRs (excluding renovate bot PRs)

[torn sonnet]

What do you want to PR?

[coarse ginkgo]

a few fixes for forks of forks

for example ./gradlew rebuildForkOfPaperPatches rebuildAllServerPatches doesn't work for forks of forks, you have to run these tasks separately

[torn sonnet]

Neat!

If you already wrote the code, you could PR it. If you're not sure about if it might get accepted or not and don't want to waste time writing it, you could throw up an issue

[coarse ginkgo]

yeah, I already fixed the issue locally, I'll clean up a bit and PR it soon then

[coarse ginkgo]

https://github.com/PaperMC/paperweight/pull/388 👀

[lucid mulch]

Hey so i have thought of a workaround, for the issues described above and pushed it. If this plugin gets applied right in the paper-api (so by Paper) build file then the dependencies should always exist and nothing will fail, and if it isn't applied then there's simply no classpath for AT (it only causes Adventure related methods to fail) on the first invocation, and it gets only attached in subsequent ones
I know it's not the best gradle practice but it works so, and this is the best solution I could come up with given the subproject build files are generated dynamically so gradle can't even evaluate those subproject before upstream apply finishes, at which point its out of the config phase and it will only evaluate during the second invocation 😛

Given the constraints in which paperweight operates this seems like the best solution and also matches other things too, but as always if anyone has a better idea feel free to review. And I don't mean to push but this has been open for a long time now with no review from the team, i get if its low priority but it'd be nice for this to be merged before the non-snapshot releases

[halcyon gale]

Hello, is there any plan to update paperweight-example (fork) ? I've not done MC dev for quite a few years now and I would like to start on a correct basis.
As always, thanks for all the work

[lucid mulch]

ill pr in a sec, and you can use that!

[static urchin]

please don't, we are waiting for some parts of our toolchain to be cut into releases

[lucid mulch]

why tho

[lucid mulch]

ah okay then

[lucid mulch]

also idk if youve seen but patcher doesnt work with gradle 9.5.0

i reported it on github

[halcyon gale]

I'll wait bit then; thanks for trying karmuss 🙂

[lethal nebula]

Hey I'm having some trouble setting up paperweight, having an issue with shadowJarwhere it says something like Could not add META-INF to ZIP . I just switched from paper -> paperweight cuz I wanted to use NMS but I'm having this issue with building.

[turbid moon]

@lethal nebula ^^

[lethal nebula]

Nvm I fixed it, it was a shadow issue I used com.gradleup.shadow (version 9.3.1) instead of com.github.johnrengelman.shadow and it built perfectly fine

[paper forum]

Hello! Does anyone know why Jpenilla's run task give me this error?

Execution failed for task ':runServer'.
> Unknown Paper Version: 26.1.2

[paper forum]

Nvm, had to update the version

[ruby ether]

yo im trying to load adventure NBT and its not loading
<dependency>
<groupId>net.kyori</groupId>
<artifactId>adventure-nbt</artifactId>
<version>4.26.1</version>
</dependency>

Cannot resolve symbol 'CompoundBinaryTag'
import net.kyori.adventure.nbt.CompoundBinaryTag;

[final jewel]

what does mvn dependency:tree -Dverbose show

put the output in a paste

[ruby ether]

POST https://api.pastes.dev/post net::ERR_SSL_PROTOCOL_ERROR
i can't.

[final jewel]

first time I see that error, well you can just use a different one like https://pastee.dev/

[ruby ether]

ill just use pastebin
https://pastebin.com/Dz9Dd8Hm

[final jewel]

you seem to be trying to use adventure-nbt 5.0 while you're using adventure 4.26.1

[ruby ether]

ok let me try that

[final jewel]

you also seem to be declaring adventure yourself, is that for a specific reason?

[ruby ether]

BRO WHY THE HELL DID THAT FIX IT??

[ruby ether]

wdym

[final jewel]

oh it isn't a plugin, nevermind

[ruby ether]

lol

[final jewel]

I would recommend using adventure-bom to avoid dealing with issues like that

[ruby ether]

Cannot resolve symbol 'minimessage'

yay.

IM LOADING MINIMESSAGE

THE HELL DO YOU MEAN

'import net.kyori.adventure.text.minimessage.MiniMessage;'

[fading vapor]

is this a compile error or your IDE saying that?

[ruby ether]

my IDE

[final jewel]

does it tell you the same thing if you do mvn package?

[fading vapor]

then try building first and if it infact fails try to fix the code, otherwise your IDE is acting up

[ruby ether]

i mean i haven't migrated my nbt stuff over yet

but sure ill do it

and see

[final jewel]

well, ignoring other errors you might have, see if it tells you it cannot find the symbol MiniMessage

[ruby ether]

ehh no

[final jewel]

if it doesn't then it might just be your ide

[ruby ether]

kk

let me do a full reload of my IDE

[final jewel]

if it is IntelliJ, you can clear caches

[ruby ether]

ye

let me do that

oop nvm

i reloaded projects and it fixed

[final jewel]

great

[ruby ether]

god i hate intellj

but its the best ide

alright im gonna start asking junk in #adventure-help

[ruby ether]

im trying to find the library for "import net.kyori.adventure.text.serializer.json.legacyimpl.NBTLegacyHoverEventSerializer;
", i seen this from velocity for its serializers so uh.. whats it called so i can put it in the dependencies

found it! its just adventure-text-serializer-json-legacy-impl

NVM lol

[mint marsh]

https://pastebin.com/TLzbLW7V

@fossil topaz

[fossil topaz]

There should be a print fork version task, can you send the output of executing it?

[mint marsh]

./gradlew printPaperVersion
Reusing configuration cache.

> Task :printPaperVersion
unspecified

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed
Configuration cache entry reused.

[fossil topaz]

And is this a proper fork, or is this a git fork of paper repo?

[mint marsh]

git fork on my personal github

[fossil topaz]

You're most probably breaking somehow the version in one of your commits, try to check for relevant changes in all gradle files in all the commits ahead of paper

But it's really not that good to keep a fork of paper as a git fork, you should consider making a proper fork, even for that smaller change

[mint marsh]

Im up to date and my single change is on top

The server jar does work fine. its live now, its just its not reporting the version correctly and some plugins freak out and disable themselves

[fossil topaz]

But if you'll clone a brand new paper in a different foldr and run the print command what it'll print?

[mint marsh]

@fossil topaz found the issue. Stale Gradle configuration cache.
This fixed it for future reference:

./gradlew --stop              
Remove-Item -Recurse -Force .gradle\configuration-cache

Thanks for the help

[teal cloud]

I use ${project.version} to display my version but it doesn't work

paper-plugin.yml
version: ${project.version}

[torn sonnet]

Well, what are you doing to try to make it work? What's in your build script?

[teal cloud]

What exactly do you mean by what's in my build script? A copy of it is here: https://github.com/SQD-Studios/KuraAC/blob/master/build.gradle.kts

[torn sonnet]

In order for that to be replaced, you need to have instructed your build script to replace it.

[brisk belfry]

@green slate

Yes

And now run it

[green slate]

Unknown Paper Version (failed to fetch or find in local cache): 26.1.2

now its this

@brisk belfry

[brisk belfry]

Can you do gradle cleanand try again

[bronze ember]

./gradlew clean

[brisk belfry]

Go to the gradle tool window in IntelliJ and locate „clean“ then double click it

[green slate]

yeah im trying

this?

[brisk belfry]

No

[green slate]

?

[brisk belfry]

clean

Just clean

[green slate]

nvrmd found it

ok cleaned

[brisk belfry]

And now try again

[green slate]

Unknown Paper Version (failed to fetch or find in local cache): 26.1.2

[brisk belfry]

Okay now click on Run: Failed

And paste the whole tex tragt shows into

[green slate]

Unknown Paper Version (failed to fetch or find in local cache): 26.1.2

• 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 117ms
11 11 34 AM: Execution finished 'runServer'.

[brisk belfry]

Scroll up?

[green slate]

11 11 34 AM: Executing 'runServer'…

Task :compileJava UP-TO-DATE
Task :processResources UP-TO-DATE
Task :classes UP-TO-DATE
Task :jar UP-TO-DATE
Task :runServer FAILED
4 actionable tasks: 1 executed, 3 up-to-date

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':runServer'.

Unknown Paper Version (failed to fetch or find in local cache): 26.1.2

• 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 117ms
11 11 34 AM: Execution finished 'runServer'.

idk what to do

[bronze ember]

run with --debug

[brisk belfry]

Run with —debug

[bronze ember]

u 2 slow m8

[green slate]

wait

how

[brisk belfry]

Inside your run configuration

[brisk belfry]

Yeah

In that text input

The text below it even shows you an example with the debut option

[brisk belfry]

Yes

Now run again

[green slate]

and above it is all white

[bronze ember]

for the love of god, how hard can it be to post a full log output to a paste site

[green slate]

paste site>

?

[bronze ember]

yeah I give up

[brisk belfry]

I just sent you the link

[brisk belfry]

Here

[brisk belfry]

😆

[green slate]

https://pastes.dev/nkzMd835zk

10k lines bruh

2k*

[green slate]

ok bro we all start somewhere

[brisk belfry]

I’m on my phone I can barely read this maybe someone else can try to read what it says

[green slate]

bro how can you read 2k lines

@bronze ember

https://pastes.dev/krw0STEKQd

idk why this happen @brisk belfry

[brisk belfry]

Please stop pinging people

[raven barn]

send a screenshot of thise tab in your ide

[bronze ember]

for some reason even that includes no logging from run-task

[brisk belfry]

Is a possible reason that run-task is on gradle 9.1.0 and they are using 9.4.0? I doubt it but everything is possible

[raven barn]

it rather looks to me like they are running in gradle offline mode

[brisk belfry]

Ah maybe

[bronze ember]

but it should still log abotu that

[raven barn]

¯_(ツ)_/¯

[green slate]

ok

[green slate]

hm

im not in offline mode

[brisk belfry]

Can you click on this icon (refresh) and post the output in a paste

[green slate]

Task :prepareKotlinBuildScriptModel UP-TO-DATE
Download https://services.gradle.org/distributions/gradle-9.4.0-src.zip, took 892 ms
Could not resolve Gradle distribution sources. See debug logs for details.
Could not resolve Gradle distribution sources. See debug logs for details.

[Incubating] Problems report is available at: file:///C:/Users/USER/Desktop/untitled/build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.4.0/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 1s

[green slate]

small ouitput

output)

:(

[brisk belfry]

Is your project on GitHub?

[sharp coral]

Is there any hope porting to the last combat snapshot which is 1.16.2 based

[fading vapor]

that version isnt supported and therefore you are on your own

[bronze ember]

What exactly do you want to port? The changes of that snapshot to 26.2? It's def possible that way around, just need to get a diff to 1.16.2 I guess

[sharp coral]

1.16.2 paper server jar for that snapshot

[bronze ember]

Ah ye same idea

[sharp coral]

I tried buildtools method which seems to require forge for that era

[bronze ember]

Get a diff to vanilla, see how bad that is and then apply it to paper

Oh ye building a old paper version might be involved, it doesn't require forge but maybe it's a lib you are missing

If that isn't on a repo anymore you will have to hunt it down and publish it to your local repo or something

[sharp coral]

Lemme try playing with paper-archive

But like the spigot porting process seems to require some srg mapping file eventually

[bronze ember]

I would ignore spigot

But yes to make your life easier you will have to map the vanilla and the combat jar to whatever mappings paper used at the time

Idk if we used paperweight back then or the cursed shell scripts, but some where in there you will find the code for how to do that

[sharp coral]

The cursed shell scripts seem to be working tho

its building a unmodifed 1.16.5 jar properly

[lucid mulch]

is this something that would get accepted into paperweight?

A task that works the same way as fixup per-file patches but for feature patches

with an option to pass in the patch number through a CLI arg

--patch-number

[proud maple]

so basically a shortcut for git stash and git rebase?

[lucid mulch]

yea

tbh the fixup per file patches task is the same thing xD

[bronze ember]

Or a fixup commit and rebase

Idk I don't hate it

[lucid mulch]

https://github.com/PaperMC/paperweight/pull/390
opened a pr in that case

[sharp coral]

I got very close, all i need is to regenerate classes csrg file

members can be regenerated by spigot buildtools

[white arrow]

I've been using hot reloading with the jetbrains runtime and -XX:+AllowEnhancedClassRedefinition in IntelliJ for debugging and fast iteration.

However, I've been getting "java.lang.NullPointerException: Cannot throw exception because "null" is null" in the reloaded code so often that hot reloading is barely usable. I believe this to be potentially Kotlin related but I'm not sure. Does anyone know a fix to this? Its very annoying

This is my run server task:

tasks.withType(xyz.jpenilla.runpaper.task.RunServer::class) {
    javaLauncher = javaToolchains.launcherFor {
        vendor = JvmVendorSpec.JETBRAINS
        languageVersion = JavaLanguageVersion.of(25)
    }
    minecraftVersion("1.21.11")
    serverJar(file(project.projectDir.resolve("run/paper.jar")))

    jvmArgs("-XX:+AllowEnhancedClassRedefinition")
    jvmArgs("-Dcom.mojang.eula.agree=true")
}

the error sometimes even happens when I just change a constant parameter to a method call

[final jewel]

What type of code did you change exactly

The thing with hotswapping is that you have to be careful of not accidentally making state inaccessible

Usually just comes down to avoiding static fields, and just making sure to reload places where an instance of your might be used

[white arrow]

E.g. changing

randomMethod(50)
to randomMethod(60)

Is already breaking it. Its a 50/50 chance it works

[final jewel]

Be more explicit

Is it on a command executor? Because those you may need to reload with /minecraft:command aside from the hotswapping

[white arrow]

my inventory creation functions mostly, but happens with literally everything

I think it might just be a kotlin thing

but maybe a kotlin user has any ideo on how to fix it maybe?

I could imagine the null stuff beeing from kotlin nullability checking

This proguard issue might be related https://github.com/Guardsquare/proguard/issues/375 although I'm not using suspend functions right now

(and I'm not using proguard)

[final jewel]

I doubt it, kotlin shouldn’t generate bytecode that different. If anything hotswapping often has issues with lambda captures

If you encounter the issue again, and you can show a specific error and piece of code I can tell you why it might happen, however it isn’t something that just happens, it is often an issue of how the code is structured

[white arrow]

I'll try to make it happen on something where I dont have to show a bunch of internals

[white arrow]

Adding this println statement just triggered it...

java.lang.NullPointerException: Cannot throw exception because "null" is null
    at CafeLobby-1.0-SNAPSHOT-all.jar//net.cafestube.lobby.listener.PlayerListener.handle(PlayerListener.kt) ~[?:?]
    at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:80) ~[cafepaper-api-1.21.11-R0.1-SNAPSHOT.jar:?]
    at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:71) ~[cafepaper-api-1.21.11-R0.1-SNAPSHOT.jar:?]
    at io.papermc.paper.plugin.manager.PaperEventManager.callEvent(PaperEventManager.java:54) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.callEvent(PaperPluginManagerImpl.java:131) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:628) ~[cafepaper-api-1.21.11-R0.1-SNAPSHOT.jar:?]
    at io.papermc.paper.adventure.ChatProcessor.post(ChatProcessor.java:378) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at io.papermc.paper.adventure.ChatProcessor.processModern(ChatProcessor.java:151) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at io.papermc.paper.adventure.ChatProcessor.process(ChatProcessor.java:115) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at net.minecraft.server.network.ServerGamePacketListenerImpl.chat(ServerGamePacketListenerImpl.java:2553) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at net.minecraft.server.network.ServerGamePacketListenerImpl.broadcastChatMessage(ServerGamePacketListenerImpl.java:2591) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at net.minecraft.server.network.ServerGamePacketListenerImpl.lambda$handleChat$10(ServerGamePacketListenerImpl.java:2333) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at net.minecraft.util.FutureChain.lambda$append$1(FutureChain.java:25) ~[cafepaper-1.21.11.jar:1.21.11-DEV-cdee41a]
    at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire$$$capture(CompletableFuture.java:739) ~[?:?]
    at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java) ~[?:?]
    at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:503) ~[?:?]
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090) ~[?:?]
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) ~[?:?]
    at java.base/java.lang.Thread.run(Thread.java:1474) ~[?:?]```

changed nothing else

and now it seems like every method in the same class is broken too

didnt even notice that before

[final jewel]

Does it still happen if you reload the listener instance?

[white arrow]

wdym? Re-instantiate and re-register it?

[final jewel]

HandlerList.unregisterAll(currentListenerInstance) then new instance and registerEvents again

[white arrow]

lemme implement some handler that does this, one sec

[final jewel]

I do that with a command usually, makes things easy

[white arrow]

[19:51:57 INFO]: MenschenToaster issued server command: /test
[19:51:57 ERROR]: Command exception: /test
java.lang.NullPointerException: Cannot throw exception because "null" is null
at CafeLobby-1.0-SNAPSHOT-all.jar//net.cafestube.lobby.listener.PlayerListener.<init>(PlayerListener.kt) ~[?:?]
at CafeLobby-1.0-SNAPSHOT-all.jar//net.cafestube.lobby.CafeLobby.onEnable$lambda$1(CafeLobby.kt:222) ~[?:?]
at io.papermc.paper.command.brigadier.PaperCommands.lambda$register$3(PaperCommands.java:181) ~[cafepaper-1.21.11.jar:?]

It fails to invoke the constructor...

This is my command:
registerCommand("test") { stack, args ->
HandlerList.unregisterAll(playerListener)
playerListener = PlayerListener(this)
server.pluginManager.registerEvents(playerListener, this)
}

it took me a few tries. It worked for like 9 attempts and then broke

sometimes it breaks instantly

sometimes I can go through a lot of reloads without error

[final jewel]

Hm, I’ll give it a try myself back at home to make sure it is not just the bytecode generated or something else

Will ping you if I experience the same & find a solution

[white arrow]

Pressing Ctrl Shift F9, which is the hot reload keybind, it invokes the classes gradle task.

I then copied one of the classes that failed (I actually didnt even change anything in there??? But the bukkit task just kept throwing the exception anyway). I put it into recaf and the bytecode looks good

It must be the JVM doing some shady stuff somewhere I guess? I attached visualvm as it shows me the jvm flags and -XX:+AllowEnhancedClassRedefinition and the IntelliJIdea2026.1\captureAgent\debugger-agent.jar agent are applied normally

-# (Looking at that old code I am now asking myself why this is named lobby player pool if it isn't even a pool lol - lemme rename that)

[raven chasm]

Hey are yall still helping people with 1.21.11 builds or not anymore now that 26.1 is stable?

[final jewel]

if you had just asked your question you might've gotten an answer from someone unknownly but now I just gotta tell you no

[raven chasm]

its specifically to do with mappings, so it would've been easy to tell

thanks though!

[final jewel]

though I guess if it is a question about paperweight it should be fine given that hasn't yet been completely updated anyway (or well, at least the examples repo hasn't)

[raven chasm]

sorta?

[fading vapor]

isn't 1.12.11 still supported tho?

[raven chasm]

I'm wondering how I can take my 1.21.11 project and build it for 26.1.2. The reobfJar task shouldn't be used, so I think I can just remove it

but I still want the 1.21.11 build for backwards compatability

i was thinking abt symlinking the 1.21.11 dir to another spot and only using reobfJar on one "build", but if there's an easier way, that'd be better

I know I can just build it twice and remove the task for the second run, but I'd like to get both jars in 1 go

[novel knoll]

you also don't need to reobf for 1.21.11 😄 we've been running mojang mappings for a good while now

[raven chasm]

ah, good to know!

thanks!

[fading vapor]

basically nowadays you just need to run build or shadowJar if you're shading anything

reobfJar is a thing of the past

[novel knoll]

the only reason you "needed" to reobf if you wanted to keep spigot compatibility, but since hardfork compatibility between the two is far from a guarantee and will only become a more and more arduous task as time goes on, so you should a) really consider if you wanna targeting spigot, and b) if you do, treat spigot and paper as two entirely different platforms in the same sense forge and neoforge are two completely separate platforms now, and publish two jars, one for each

[raven chasm]

Yeah, I'm looking to convert the thing to other platforms. I like the kyori api too much to hope to maintain spigot compat for now

[long stirrup]

Not sure if this fits here or #paper-dev, but I figured this is more fit here.

I am working with a private server with its own need of plugins. They are many homegrown plugins that are needed (say A, B, and C). What would be the way people prefer to structure this?

I am thinking of this being a monorepo with a monolith style, where gradle just bundles A, B, and C as modules into a single jar instead of separating A, B, and C into its own plugins and repos

[bronze ember]

I wouldn't even bother with modules, just packages

And then slap arch unit on it to make sure you don't create dum dependencies between your packages

Only using some form of events internally

Like you would have a punishment package with commands, listeners, DB stuff, business logic etc, and then the same for let's say stats

Don't have giant command packages, subdivide it by feature/domain

[long stirrup]

Makes sense, so it would be something like
name.name.name.[A|B|C] fully under the same package?

[bronze ember]

Yeah, but keep the domains really small

Ideally that also allows you to even unit test the business logic of each domain independently

[long stirrup]

Can you elaborate on keeping the domain small? I am clueless when it comes to this, never used Java or Kotlin in a proper way before (in terms of maintainable code structuring)

For example, if there was a db need, would it be like splitting
name.name.name.pluginA.db
name.name.name.pluginB.db
and not conflating the two for easier testing?

[bronze ember]

I would have the general DB setup as one domain but split the domain specific stuff

[undone drum]

is it possible to build a plugin on phone?

[bronze ember]

Like the models and schemas and queries don't belong in the general DB domain

[long stirrup]

Right, that makes sense. So things like db entities would be in its own module?

[bronze ember]

I gotta run, but the stuff I am hinting at is called domain driven design (DDD) and Command query responsibility segregation (cqrs), but are generally advanced and complicated topics and might be overkill for your first plugin, lol

They also can get quite extreme and abstract, I wouldn't do that

[long stirrup]

I'll read up into this And this will be my 4th or 5th plugin, so I am happy to (try to) adopt a design principle that'd make good code

[bronze ember]

The entities for the punishment domain would be in the punishment domain, so it's package (or subpackage)

[long stirrup]

but thank you for the time! I'll read up on DDD, and that makes sense on db entities living for whatever owns it

[bronze ember]

Sure, if you have a working development environment, like a proper jdk and your build tool of choice

[undone drum]

is my build correct

[bronze ember]

Try it and see, lol

Generally, that sounds like pain

[hot horizon]

where are the server files from runServer stored? I want to reset the world inside it

[elfin valley]

./run under the project folder

[stable aspen]

> Task :paper-server:applySourcePatches
[WARN] Patching: net/minecraft/world/item/component/Consumable.java
[WARN]  Hunk 0: FAILURE: @@ -68,8 +68,13 @@

> Task :paper-server:applySourcePatches FAILED

Execution failed for task ':paper-server:applySourcePatches'.
> java.lang.Exception: Failed to apply 1/3095 hunks

* 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 1m 55s
18 actionable tasks: 17 executed, 1 from cache
Configuration cache entry reused.

how can I fix that

I don't remember what did I do to the consumable class, now I only want to reset it

I rollbacked my commit, problem solved

[faint iris]

Trying to build a paper fork, and it's lacking the craftbukkit classes for some reason

Could not find or load main class org.bukkit.craftbukkit.Main

I've already tried nuking the paperweight cache and reapplying all the patches

[faint iris]

Running io.papermc.paperweight.patcher version 2.0.0-beta.18, gradle 9.5.0, 1.21.8 aspaper fork

Running build makes the unit tests fail as they can't see bundled classes (weird), running createMojmapBundlerJar works but the bundler jar doesn't contain any craftbukkit classes

Running runServer appears to work with this new gradle version (odd), but rebuilding the bundler jar still fails

[lucid mulch]

paperweight-patcher is incompatible with gradle 9.5.0

use 9.4.1 at most

[faint iris]

Huh

That's odd because most of my issues ocurred when I was on gradle 8

[lucid mulch]

you might have wrongly configured your fork’s build file

[faint iris]

I updated to gradle 9.5 as a troubleshooting step and it fixed most of it

[lucid mulch]

look at the examples repo

[faint iris]

wiping caches, attempting a couple more rebuilds seems to have fixed it and it works fine now on 9.5.0

[lucid mulch]

you need to add the paper-server directory as a source dir

[faint iris]

It's there yea

[lucid mulch]

can you upload ur build files here?

use https://pastes.dev

[faint iris]

I mean the problem just solved itself but sure might be useful for someone later

[lucid mulch]

weird lol

gradle is weird in itself

[faint iris]

https://pastes.dev/hjSWHABvqM

yea