build-tooling-help

[static urchin]

Yea whatever the userdev plugin is chilling in

[rocky geyser]

https://pastes.dev/EO0lqPpg1N

[static urchin]

mhm, I presume that module is inheriting a java toolchain?

[rocky geyser]

? what is a java toolchain (i'm just forking a project that made physics in minecraft cuz it's made for 1.19.2, and the shaded packetevents is outdated)

[static urchin]

oh

Well that would control what java version this is run with

which seems to be the issue

that project is public then? can you throw me the link to its github

[rocky geyser]

yeah

https://github.com/aecsocket/rattle

all i've edited is upgrading the versions of some of the depends

[static urchin]

Yea, it toolchains to java 19

idk if you just switch to java 21 without it completely exploding (mostly because idk if the fabric tooling survives that)

[rocky geyser]

i rmed the fabric part

[static urchin]

ah

build-logic/src/main/kotlin/java-conventions.gradle.kts

flip that 19 to a 21

[rocky geyser]

it was causing issues before and i didn't need it so

[mint compass]

Is there any way to make launching localhost really fast?

[granite valve]

you mean like starting up a server to test your plugin, or test the server or what?

[bronze ember]

Run-task gradle plugin makes it super fast to start a paper test server for your plugin if that's what you want

[mint compass]

starting up a server to test my plugins

[bronze ember]

Run-task is what you want then

[brave widget]

https://docs.papermc.io/paper/dev/project-setup

[bronze ember]

I believe it's mentioned here

[turbid moon]

It's mentioned completely at the bottom in a small side note

[grand crypt]

I'm working on a paper fork, and I was trying to add previously missing source files from the mc-dev-src to the project, when I did that, I'm having merge conflicts when trying to build the project again from the patches. Is there like a mappings file or something where it is specified which source files are decompiled and patched, and which are left in "mc-dev-sources"? I would like to add two or three files to modify their behavior in my fork.

warning: 1 line adds whitespace errors.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (add/add): Merge conflict in src/main/java/net/minecraft/world/item/enchantment/effects/PlaySoundEffect.java
Auto-merging src/main/java/net/minecraft/world/item/enchantment/effects/PlaySoundEffect.java
CONFLICT (add/add): Merge conflict in src/main/java/net/minecraft/world/item/MaceItem.java
Auto-merging src/main/java/net/minecraft/world/item/MaceItem.java
CONFLICT (add/add): Merge conflict in src/main/java/net/minecraft/world/item/BottleItem.java
Auto-merging src/main/java/net/minecraft/world/item/BottleItem.java
CONFLICT (add/add): Merge conflict in src/main/java/net/minecraft/world/effect/MobEffect.java
Auto-merging src/main/java/net/minecraft/world/effect/MobEffect.java

[lament scarab]

On applying patches the thing will copy the sources over from the decomp tree for you

This is generally why the flow was to add the dev import, then reapply and do your changes

If you just copy the files around manually you’ll have to deal with your patch file showing it adding the full file, and the dev imports commit pulling the unmodified file

[grand crypt]

thanks for the reply, how do i add the dev import?

[lament scarab]

https://github.com/PaperMC/paperweight-examples/blob/main/build-data/dev-imports.txt

[grand crypt]

yep got it thanks for the help

[lusty canyon]

Hi I am trying to update to the newest paper and userdev and although locally the build works just fine, on github actions it fails with following:

Run ./gradlew assemble
Downloading https://services.gradle.org/distributions/gradle-8.12-bin.zip
.............10%.............20%.............30%.............40%.............50%.............60%.............70%.............80%.............90%.............100%

Welcome to Gradle 8.12!

Here are the highlights of this release:
 - Enhanced error and warning reporting with the Problems API
 - File-system watching support on Alpine Linux
 - Build and test Swift 6 libraries and apps

For more details see https://docs.gradle.org/8.12/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
> Task :buildSrc:compileJava
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes
> Task :buildSrc:jar

2 actionable tasks: 2 executed
FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'Cithare'.
> Failed to notify project evaluation listener.
   > 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.
> Get more help at https://help.gradle.org.

BUILD FAILED in 1m 12s
Error: Process completed with exit code 1.

I am using the latest gradle with Java 21 temurin. What could cause this issue?

[verbal skiff]

Hey, what is the recommended way to set a minimum required java version? I have something like this:

allprojects {
    java {
        toolchain.languageVersion.set(JavaLanguageVersion.of(21))
    }
}

but it fails if I only have java 23 installed on my machine

[lament scarab]

That sets the toolchain (which sets defaults for the target, etc)

Can set the target, etck manually, but, that won't touch the toolchain

Use the foojay conventions plugin and the thing can look for or download the required jdk

[verbal skiff]

okay, seems kinda weird to need a plugin for something as basic as this

shouldnt this be in the default java or kotlin plugin?

and why does it fail if I have a newer java version than required

[static urchin]

why would it

usually you can just compile down with java 23 compiler for a java 21 project

[verbal skiff]

yeah well i have java 23 installed and this line crashes my build

* What went wrong:
Could not resolve all dependencies for configuration ':compileClasspath'.
Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
Cannot find a Java installation on your machine matching this tasks requirements: {languageVersion=21, vendor=any vendor, implementation=vendor-specific} for MAC_OS on aarch64.
No locally installed toolchains match and toolchain download repositories have not been configured.

[static urchin]

well yea, because we are a in a very funny project setup

[verbal skiff]

I also dont really want to do this auto download stuff

my jdk is managed through my package manager

[static urchin]

you do you lol, you don't need to use the toolchain

tasks.withType<JavaCompile> {
    options.release = 21
}

works too

[verbal skiff]

okay you know what

i dont even know why i had the toolchain part

already had this

    kotlin {
        compilerOptions {
            jvmTarget = JvmTarget.JVM_21

and theres no java code in this repo

[static urchin]

[verbal skiff]

a deletion is the best kind of commit :)

[faint hill]

I'm updating a plugin from 1.20.4 to 1.21.3, and after updating the version for the devBundle (paperweight userdev), lombok no longer generates any code and I'm receiving a NPE error during compileJava. I'm not sure if the NPE is just related to lombok failing or not, but any ideas what's causing this?
build.gradle.kts: https://paste.projecteden.gg/omire.stylus
NPE: https://paste.projecteden.gg/jahem.stylus

Updating gradle/userdev by itself is fine, it's when I swap the devBundle to the new version does it stop generating any classes/methods

[bronze ember]

Only time I saw javac output a npe was when I had an early jdk, so make sure you are on the latest update? Also try using an official dev bundle to make sure your dev bundle isn't the issue

Lombok is a giant hack so wouldn't be surprised if that ruins stuff

Especially since that stack trace mentions annotation processing

[faint hill]

Hmmm, it may be our dev bundle? At leat it changes the error to be missing things our bundle adds, so it's a different error at least...

[faint hill]

Actually, I'm not sure if it is. I tested with a different project and it builds fine with either paper's devbundle or ours

[bronze ember]

Does that also use Lombok?

[faint hill]

Yep

Not as extensively, but it does utilize getters/setters

[south lily]

plugins {
    id "io.papermc.paperweight.userdev" version "1.7.0"
}

dependencies {
    paperweight.devBundle("me.krutikov.purpur", "1.20.1-R0.1-SNAPSHOT") // paper 1.20
}

tasks {
    build {
        dependsOn(reobfJar)
    }

    reobfJar {
        outputJar.set(new File(rootDir, "../output/xxx.jar"))
    }
}

[distant mango]

try updating paperweight

[bitter linden]

Having trouble updating my fork to latest Paper commit. I thought I had the new system all down, but build.gradle.kts was changed upstream, and it seems to be failing to apply my fork's build.gradle.kts changes after running ./gradlew applyAllPatches. So, I reapplied my diff to spaper-server/build.gradle.kts, ran ./gradlew rebuildPaperServerFilePatches, but nothing was changed in that build.gradle.kts.patch file. and running applyAllPatches again fails with same error. https://pastebin.com/raw/RHNbQ61m. It's also gitignored, could that be why? https://github.com/PaperMC/paperweight-examples/blob/v2-fork/.gitignore#L9

[bronze ember]

Try looking what other rebuild tasks there are

I can't keep track of the names either

[south lily]

I installed version 1.7.7, everything is the same

[main mica]

check that gradle is using the correct JDK version. iirc gradle -v shows that (or gradlew if using the wrapper).
By default it might not use the correct one. You can specify the version in your build file to fix that, like in the example file: https://github.com/PaperMC/paperweight-test-plugin/blob/master/build.gradle.kts

[south lily]

I have Java 16 written there, but there is a special setting in Intellij Idea to specify which grade to use Java, it costs 21

[main mica]

The build file will have a higher priority, you need to set that to 21 too

[unique totem]

Just got this, changed nothing to my build.gradle, it was working before, but after it redownloaded some jars I think from paperweight.

reofJar.log
https://pastebin.com/SiC2nwnF

build.gradle
https://pastebin.com/72CqnrJc

[smoky violet]

update paperweight

[south lily]

Which version do you recommend?

[smoky violet]

latest

beta 10

https://plugins.gradle.org/plugin/io.papermc.paperweight.userdev

[smoky violet]

rebuildPaperServerFilePatches is referring to paper-server-patches

rebuildPaperPatches would be patches defined in the root build file, more specifically you can use the task for single file patches (the build scripts)

also you can use apply*SingleFilePatchesFuzzy to help with updating

[south lily]

I set it up, but I get errors.
https://paste.md-5.net/iqatatuyis.coffeescript

[smoky violet]

intellij does this annoying thing where the root project 'tasks' view will also include tasks from subprojects, but everything has descriptions

[smoky violet]

• Incompatible because this component declares a component, as well as attribute 'org.gradle.plugin.api-version' with value '8.11.1' and the consumer needed a component, as well as attribute 'org.gradle.plugin.api-version' with value '8.5'

it's telling you it's incompatible because userdev requires gradle 8.11.1 or newer

use 8.12

[bitter linden]

Seems to work after updating the paper ref, applyAllPatches, fails for hunk -> applyPaperServerFilePatchesFuzzy -> rebuildPaperSingleFilePatches. Not sure if I lost anything yet but applyAllPatches works again. Thanks!

[smoky violet]

when it fails on the build file patches it won't continue to patch server, api, etc

so you would want to retry apply all and then rebuild everything

and then of course check the git diff before comitting

[south lily]

🥹 🙏

[atomic kernel]

Execution failed for task ':reobfJar'.

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

Exception in thread "main" java.lang.RuntimeException: invalid new source ns mojang: not in [spigot] or mojang+yarn
    at net.fabricmc.mappingio.adapter.MappingSourceNsSwitch.visitNamespaces(MappingSourceNsSwitch.java:107)
    at net.fabricmc.mappingio.format.tiny.Tiny2FileReader.read(Tiny2FileReader.java:86)
    at net.fabricmc.mappingio.format.tiny.Tiny2FileReader.read(Tiny2FileReader.java:55)
    at net.fabricmc.mappingio.MappingReader.read(MappingReader.java:225)
    at net.fabricmc.mappingio.MappingReader.read(MappingReader.java:206)
    at net.fabricmc.tinyremapper.TinyUtils.read(TinyUtils.java:90)
    at net.fabricmc.tinyremapper.TinyUtils.lambda$createTinyMappingProvider$0(TinyUtils.java:48)
    at net.fabricmc.tinyremapper.TinyRemapper.loadMappings(TinyRemapper.java:703)
    at net.fabricmc.tinyremapper.TinyRemapper.refresh(TinyRemapper.java:1061)
    at net.fabricmc.tinyremapper.TinyRemapper.apply(TinyRemapper.java:914)
    at net.fabricmc.tinyremapper.TinyRemapper.apply(TinyRemapper.java:903)
    at net.fabricmc.tinyremapper.Main.main(Main.java:265)

I get this error, I am using gradle 8.12 and paperweight userdev version 2.0.0-beta.10

[proud maple]

share your build file

[atomic kernel]

    id 'java'
    id 'io.freefair.lombok' version '8.6'
    id 'io.papermc.paperweight.userdev' version '2.0.0-beta.10'
}

group = 'x.x'
version = '1.0-SNAPSHOT'

repositories {
    mavenCentral()
    mavenLocal()
}

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8'
    options.release.set(21)
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

dependencies {
    paperweight.paperDevBundle('1.21.4-R0.1-SNAPSHOT')
}

tasks.reobfJar {
    dependsOn jar
}

tasks.build {
    dependsOn 'reobfJar'
}

tasks.assemble {
    dependsOn tasks.reobfJar
}```

[distant mango]

you can remove that tasks.reobfJar and tasks.build fyi

[atomic kernel]

that gives me this message Task ':reobfJar' uses this output of task ':jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

[distant mango]

is that the full build script

also just because lombok can be weird try without it

[lament scarab]

I mean, I saw just getting that error building some rando plugin, bumping to .10 fixed it, sooo

maybe run with --refreshDependencies

I'm guessing you got an outdated bundle which doesn't work with that beta

otherwise,no idea

(unless you're expecting to be able to run on spigot, no reason to use reobfjar)

[night oriole]

if u still havent fixed it

[smoky violet]

this is the case

adding the dev bundle to compileOnly doesn't make any sense

[night oriole]

still works

[smoky violet]

if something is working, doing that is definitely not why

it would be in spite of that

[north girder]

https://pastebin.com/nEk58pfb I'm getting this error on paperweight 2.0.0-beta.10

[bronze ember]

Past your build file for both the parent and the 1.19 project

[north girder]

https://pastebin.com/UCnAN2rx
https://pastebin.com/Lmmi9fs1

[distant mango]

why do people always support these random releases (1.18.1, 1.20.2, 1.19.1 etc)

[bronze ember]

Mmh, pretty sure setting the tool chain like that is evil, not all versions support 21

[north girder]

I can't remember where I got that code from, but it's meant to fix that issue - it lets later versions that require java 21 compile (since they need newer java versions to use the NMS from newer minecraft versions) but it somehow compiles the code in java 17, which makes it run on earlier versions without an error

I don't really know a ton about gradle, I'm not sure how that code works, but it did fix my issue when I added it and the plugin does run on earlier versions

[smoky violet]

it's fine in v2

since you can set the java launcher for the userdev pipeline separately

and it will automatically use 17 for old bundles

but the version detection logic looks to have blown up

I missed a length check

[cinder minnow]

Hey !
Maven not longer support the ${project.version} variable into paper-plugin.yml ?

I'm asking this question because I have a plugin who's getting the hash of my latest commit from GitHub

[distant mango]

It’s not a paper issue, don’t open an issue

[cinder minnow]

Ok, but I really need to migrate to Gradle to make this working ? My plugin is really big already with a lots of dependencies

[distant mango]

I didn't say that

[smoky violet]

there's nothing special about token replacement with regards to plugin.yml or paper-plugin.yml

[cinder minnow]

That's what I see on my side to, but I don't know why it don't detect it into paper file

[slate salmon]

I mean, looking at the pom you provided in your issue, you do not seem to replace anything in a paper-plugin.yml

[lament scarab]

lol, look at your include/excludes

you're explictly pulling out some files in order to selectively run them through filtering, but, you didn't setup paper-plugin.yml to go through that

[cinder minnow]

Oh I found it, it works again, thanks

[indigo rapids]

hello! my plugin build on github actions just broke. i don't even change anything. it is just now broken. is it any way to fix it?

[lament scarab]

update the userdev plugin

(and gradle)

[indigo rapids]

oh, i just forgot to commit update of gradle and userdev

ty!

[verbal skiff]

Alright, some more gradle/kotlin weirdness. I would like to get rid of this warning:

> Task :build-logic:compileKotlin UP-TO-DATE
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target

> Configure project :catalyst-api
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target

I have set this:

    kotlin {
        compilerOptions {
            jvmTarget = JvmTarget.JVM_21
            freeCompilerArgs = listOf(
                "-opt-in=kotlin.RequiresOptIn",
                "-Xcontext-receivers",
            )
        }
    }

    tasks {
        withType<JavaCompile> {
            options.release = 21
        }
    }

I am indeed running it on java 23, but the jvm target is set to 21

also tried this, with the same result:

    tasks {
        withType<JavaCompile> {
            options.release = 21
        }
        withType<KotlinCompile> {
            compilerOptions {
                jvmTarget = JvmTarget.JVM_21
            }
        }
    }

[polar latch]

Should there be any diff between the dependencies when using paperweight and when directly taking it from maven central? I miss some Adventure stuff (Audience interface for Player) when using paperweight, but it works flawlessly when using mvn central dep and it builds in both cases. - Like IntelliJ isn't resolving the functions and it's not implemented in CommandSender when checking the sources.

[lament scarab]

Check your classpath

that would generally imply that something else is providing Player

[bronze ember]

Modern paperweight should warn when that's the case, so make sure you use 2.0.0-beta.10

(and Gradle 8.12)

[polar latch]

will try, was on 1.7.7

I hate Gradle errors

[brave widget]

message.txt by @polar latch: https://pastes.dev/AY9e1GBDRn

[distant mango]

update gradle to latest

[smoky violet]

paperweight version won't make a difference there, we only added the attributes for 1.21.4

[bronze ember]

Oh

[smoky violet]

it's in the paper-api metadata

[polar latch]

Works rn, thx everyone for help and cya

[bronze willow]

FAILURE: Build failed with an exception.

* What went wrong:
Could not create task ':velocity:runVelocity'.
Could not create task of type 'RunVelocity'.
Could not create an instance of type xyz.jpenilla.runtask.pluginsapi.DownloadPluginsSpec.
Could not generate a decorated class for type DownloadPluginsSpec.
Cannot have abstract method NamedDomainObjectSet.named().

Whats going on here? I want to run runVelocity

[smoky violet]

update gradle and gradle plugins

[bronze willow]

Thought the same now, now it works, ty

[grizzled river]

anyone know why this error is happening?
build.gradle.kts: https://pastes.dev/caUtTuh65Y

[static urchin]

Move to userdev 2.0.0-beta.11 and latest gradle

the .4 dev bundle is published with a new version

[grizzled river]

latest gradle version is 8.11 right?

[bronze willow]

.12

[grizzled river]

ty

[wary walrus]

not found erm

[static urchin]

beta11 != beta.11

[wary walrus]

aa

oh sorry

[thorn root]

would anyone have any idea what 'setAbsorptionAmount' does? at a first assumtion i thought it would give the entity absorption hearts but it doesnt seem to be working like that oddly enough

[distant mango]

sorryI meant #paper-dev 😦

idk why I typed build tooling help

[thorn root]

haha dw about it

[heavy cobalt]

Can someone help me with this please? Trying to use the latest version of paper userdev

[distant mango]

update gradle to latest

[heavy cobalt]

I m on gradle 8.11, when im on gradle 8.12 is get this

[distant mango]

try deleting the caching folder

also make sure you’re using the right java version

[heavy cobalt]

it should be 21 right

[austere robin]

So, I'm confused by the userdev stuff and I'm not sure if I should have it (and what's needed for Mojang remappings).

I've not got a paper plugin as it's marked as experimental and don't have the capacity currently to keep up with changes (or debug something that goes wrong from it). I'm on 1.21.3 and making a plugin for my server that's on 1.21.3.

[lament scarab]

if you don't need access to mojang code, then you don't need userdev

[austere robin]

Do I need specify that I'm mojang mapped tho?

[lament scarab]

You don't need to

but, if you're not using internals, then you can state that you're compatible with a mojmap'd server and not go through the remapper

[grizzled river]

how can i set an external download url instead of a jar when using the hangar publish gradle plugin?

[distant mango]

isn’t it right there in the example..?

[grizzled river]

mind showing me where? i might just be reading too fast or something: https://docs.papermc.io/misc/hangar-publishing

if you’re referring to the image i posted, that just returns an error. Not at my pc right now so i can’t show it but i figured i should clarify

[knotty pilot]

Hey, i am coding a fabric mod right now but i have a general problem with gradle... since im normally using maven and have no idea about gradle but need to use it for fabric mods, im struggling to shade a dependency into my project

this is my build.gradle: https://pastes.dev/tpcAjAGF4N

[bronze ember]

you wanna look at the gradle shadow plugin

you got the old shadow plugin, you want the one from gradleup

[knotty pilot]

i found that, but dont get how to use it... im already googling 1 hour

[knotty pilot]

oh, okay 1sec

[bronze ember]

but whats the issue you are facing?

[knotty pilot]

i try to just shade 2 of the whole dependencies since the fabric ones dont need to be shaded...

how can i tell gradle to do that?

i need

implementation "org.bspfsystems:yamlconfiguration:3.0.1"
implementation group: 'org.yaml', name: 'snakeyaml', version: '1.8'

to be shaded since they are external dependencies

[bronze ember]

I think its a bit more complicated because of baric, best to ask them

random example I found, but look how they are setting up the configurations https://github.com/DaemonicLabs/fabric-example-mod-kotlin/blob/master/build.gradle.kts

control + f "shadow" and you can look at stuff they did

[knotty pilot]

okay, thank you c:

[knotty pilot]

I tired for over an hour now and couldnt figure it out :c any further advise?

[bronze ember]

ask fabric people, lol

https://discord.gg/v6v4pMv

[rapid fractal]

Damn I didnt know we are bigger than fabric

[bronze ember]

discord.gg/papermc

huh

when did we jump so much

ok then discord

[heavy cobalt]

why am I getting this problem?
im using gradle 8.12

[static urchin]

are you sure intellij is configured to use gradle 8.12?

[heavy cobalt]

im not completely certain I suppose, this is the build tools configuration

[static urchin]

Why is there a setting.gradle.kts on the root level

and then another full gradle project inside the xc package o.O

[heavy cobalt]

this isnt something I set up. I am trying to update a rather complicated and advanced combat vehicle plugin, and I am not familiar with gradle to be quite frank. The XV module and XC module compile to separate jars, and XV depends on XC

That root level settings.gradle has only this

[static urchin]

Yea that is generally not how multi module builds look in gradle tho

[smoky violet]

just move xc/gradle to the root

[static urchin]

^

[smoky violet]

and probably delete xc/settings.gradle.kts

or copy whatever it was trying to do into the root

since it wouldn't have been used before

[glacial cipher]

WorldEdit has an optional dependency on the rhino runtime to support execution of javascript scripts. Their instructions say to put the js.jar file in the plugins or plugins/WorldEdit directory. However, as WorldEdit is remapped, the classpath ends up pointing to plugins/.paper-remapped and plugins/.paper-remapped/WorldEdit. Would it make sense for Paper to extend the classpath to include the unmapped directories in the event of a remapping?

[bronze ember]

Shouldn't worldedit make sure to load the scripts from the right folder?

Not sure what the classpath has to do with this, they should search for scripts in their data directory

[static urchin]

Well from the looks of it they just require the js.jar file to be on the classpath so they can even excute it?

I don'T think this is related to the scripts themselves, more the engine needed to run them

but eh idk why throwing it at plugins/WorldEdit would even add it? What kind of classloader fuckeries are they doing

[bronze ember]

Pretty sure you can point Nashorn to arbitrary files

[static urchin]

rhino runtime

https://worldedit.enginehub.org/en/latest/usage/other/craftscripts/

[bronze ember]

All the same to me

[quaint raven]

just as reference: https://github.com/EngineHub/WorldEdit/issues/2691#issue-2768848853

[static urchin]

Yes but it isn't in the jdk

[bronze ember]

Oh jar

Does paper have a lib folder?

That would be better for stuff like this

[distant mango]

there’s a libraries folder from the paper plugin stuff?

[static urchin]

I mean, on paper world edit can use the library loader to optionally download this stuff

but we don't actively shit the entire lib folder into the classpath

[bronze ember]

That would be better, some Boolean in the config

[static urchin]

that was like, the whole point

idek why that works on spigot either.
Like, neither the entire plugin/ nor plugin/WorldEdit folder should be on the classpath should they?
And that js.jar isn't a plugin

[bronze ember]

They have it configured in the manifest and somehow that makes the classloader loop up that relative path

[static urchin]

ah

[bronze ember]

Maybe we need to rewrite manifests

[static urchin]

Yea that makes sense

[quaint raven]

is that possible without declaring a plugin as paper-plugin?

[static urchin]

yea

We ported that to bukkit plugins too

lemme get you the PR

https://github.com/PaperMC/Paper/pull/10758

1.20.6 tho, not .5

[bronze ember]

https://github.com/EngineHub/WorldEdit/blob/version/7.3.x/build-logic/src/main/kotlin/buildlogic.platform.gradle.kts#L54

Maybe that can be rewritten?

Might be worth testing, changing the path manually and seeing if it works

[static urchin]

If you wanna fight jmp on it?

[quaint raven]

good luck

[static urchin]

probably possible but uh sounds kinda very funky

[bronze ember]

First time I see somebody using that feature, didn't even know it works for plugins

I only know it from spring, lol

[static urchin]

rewriting the path to ../../$it goes crazy

[bronze ember]

Lemme get my ass up and try

[static urchin]

might wanna @smoky violet before you invest time

[quaint raven]

wait unitl a spigot server is used in the root dir

[bronze ember]

Just manually, not touching any code, lol

[static urchin]

ah, well still a fun ping for jmp, but yea I think the plugin loader is the nicer way to solve this

can even just poke at the jar like it does rn if you wanna keep that "user has to download/supplies versions it wants"

[bronze ember]

let see how this js stuff works

[glacial cipher]

A minimal script would be just player.print("hi");

[bronze ember]

ah yes 😄

@glacial cipher what strace arguments did you use? it doesnt show any calls like that for me

oh lmao am dum

open up the jar, find /META-INF/MANIFEST.MF, change WorldEdit/js.jar under Class-Path to ../WorldEdit/js.jar

when jmp wakes up and reads the ping we can talk about this I guess, I dont see a harm in rewriting it automatically

but I also dont know if we want to acknowledge this as a feature that exists

[novel knoll]

i mean, it's a standard thing that the urlclassloader does even if you don't know about it
https://docs.oracle.com/en/java/javase/23/docs/specs/jar/jar.html#class-path-attribute jar specification

[static urchin]

The obvious solution is to just provide mojmapped world edit

which, that will have to happen sooner or later anyway soooo 😉

[bronze ember]

@ wiz 😄

[static urchin]

you mean @ joo200, we just need to pressure everyone

[bronze ember]

no clue who is in charge over there

joo I at least could physically threaten 🤔

[quaint raven]

Maddy, octy or wiz

[quaint raven]

Yea sure, but don't try it

[rocky geyser]

uhh

[crude kernel]

update IJ

[rocky geyser]

fixed it

[tranquil raven]

Hi, does paperweight userdev can be used without publishingtomaven locally?

[bronze ember]

What do you mean?

Both the Gradle plugin and the dev bundle are published to the Gradle plugin portal and our maven repo respectively

[tranquil raven]

https://docs.papermc.io/paper/dev/userdev

I followed this tutorial but i can't get it resolving

[tranquil raven]

I think i'm confused with beta/snapshot versions

[bronze ember]

What's the error?

The beta is also published to Gradle plugin portal

Make sure your Gradle is 8.12 or higher

[tranquil raven]

That could be the issue lemme check

[bronze ember]

(the error should tell you that, but Gradle resolver errors are extremely verbose instead of just suggesting what to do....)

[tranquil raven]

> Could not resolve all artifacts for configuration ':classpath'.
   > Could not resolve io.papermc.paperweight:paperweight-userdev:2.0.0-beta.11.
     Required by:
         project : > io.papermc.paperweight.userdev:io.papermc.paperweight.userdev.gradle.plugin:2.0.0-beta.11
      > No matching variant of io.papermc.paperweight:paperweight-userdev:2.0.0-beta.11 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 '8.11.1' and the consumer needed a component, as well as attribute 'org.gradle.plugin.api-version' with value '8.8'

this is what i get

so it is

indeed

[bronze ember]

Yeah you have Gradle 8.8

[tranquil raven]

Considering i'm using intellij, is it ide config or did i messed up my gradle conf of my project?

[distant mango]

gradle/arapper/wrapper something

edit the version there then run gradlew wrapper

maybe need to do that twice

[tranquil raven]

Thanks

[slender vector]

Is it possible to use paperweight with a maven project?

[main mica]

it is not

would highly recommend just migrating to Gradle (can import maven projects too).
There is a community-made nms plugin for maven, but even the dev of that recommends using Gradle instead when possible

[pallid elbow]

Did this change/move somewhere? com.velocitypowered:velocity-native:3.3.0-SNAPSHOT

[distant mango]

still exsits

are you depending on the old repo endpoint

[pallid elbow]

I believe I updated it: val paperMavenPublicUrl = "https://repo.papermc.io/repository/maven-public/"

[distant mango]

https://repo.papermc.io/#browse/browse:maven-snapshots:com%2Fvelocitypowered%2Fvelocity-native

[topaz fulcrum]

https://pastes.dev/t0z3HmrPcx

[turbid moon]

That's a maven pom. Now, what's the issue you are having?

[topaz fulcrum]

the NuVotifier dependenci is not working

like its red and saying this: Could not find artifact com.vexsoftware:nuvotifier-universal:pom:2.7.2 in spigotmc-repo (https://hub.spigotmc.org/nexus/content/repositories/snapshots/)

[turbid moon]

That's not something to do with us

You are not even using paper api

Ask in whatever plugins support that you are having issues with

[topaz fulcrum]

sorry, i was just trying to ask for help

okey

[fossil topaz]

the plugin author seems to put wrong coordinates, check https://jitpack.io/#NuVotifier/NuVotifier/2.7.2

[topaz fulcrum]

oh yeah, he does put them wrong, thx

[grizzled hamlet]

    // worldguard
    maven("https://maven.enginehub.org/repo/")
    maven("https://repo.papermc.io/repository/maven-public/")
}```
I get ```org.gradle.internal.resolve.ArtifactNotFoundException: Could not find velocity-native-3.1.2-SNAPSHOT.jar (com.velocitypowered:velocity-native:3.1.2-SNAPSHOT:20230101.180944-102).
Searched in the following locations:
    https://maven.enginehub.org/repo/com/velocitypowered/velocity-native/3.1.2-SNAPSHOT/velocity-native-3.1.2-20230101.180944-102.jar```

[turbid moon]

What does your dependencies section look like?

[bronze ember]

Post the whole build not just snippets

[grizzled hamlet]

plugins {
    kotlin("jvm") version "2.1.0"
    id("com.gradleup.shadow") version "9.0.0-beta4"
    id("io.papermc.paperweight.userdev") version "2.0.0-beta.12"
}

kotlin { jvmToolchain(17) }

repositories {
    // worldguard
    maven("https://maven.enginehub.org/repo/")
    maven("https://repo.papermc.io/repository/maven-public/")
}

configurations {
    create("resolvableImplementation") {
        isCanBeResolved = true
        isCanBeConsumed = true
    }
}

dependencies {
    compileOnly(files("lib/plugin.jar"))

    compileOnly(platform("org.jetbrains.kotlin:kotlin-bom"))

    compileOnly("org.jetbrains.kotlin:kotlin-reflect")

    compileOnly("org.tomlj:tomlj:1.1.1")
    configurations["resolvableImplementation"]("org.tomlj:tomlj:1.1.1")

    compileOnly("com.sk89q.worldguard:worldguard-bukkit:7.0.7")

    sourceSets["main"].java.srcDir("src/nms/v1_20_R1")

    paperweight.paperDevBundle("1.20.1-R0.1-SNAPSHOT")

    tasks { assemble { dependsOn(reobfJar) } }
    tasks.named("reobfJar") {
        base.archivesName = "test"
        version = "1.20.1"
    }
}

tasks {
    named<ShadowJar>("shadowJar") {
        configurations.set(mutableListOf(project.configurations.named("resolvableImplementation").get()))
        minimize()
    }
}

tasks { build { dependsOn(shadowJar) } }```

[distant mango]

figure out what’s depending on velocity native and exclude i guess?

actually probably paper

[grizzled hamlet]

i changed maven("https://maven.enginehub.org/repo/") to maven { uri("https://maven.enginehub.org/repo/") content { excludeGroup("com.sk89q.worldguard") } } and now ```Failed to notify project evaluation listener.

paperweight requires a development bundle to be added to the 'paperweightDevelopmentBundle' configuration, as well as a repository to resolve it from in order to function. Use the dependencies.paperweight extension to do this easily.```

[distant mango]

..?

[grizzled hamlet]

i think that excluding velocity only isnt a solution because the problem is that gradle tries to find velocity in enginehub repo ONLY even if i passed another repo

Like this issue is insanely stupid one lol, makes no sense

I will try to solve it once im back on pc

[grizzled hamlet]

also this is a little progress lol

"paperweight requires a development bundle to be added" blahblahblah, even though its literally in build file

[smoky violet]

pass --stacktrace, it's telling you it can't resolve a bundle

not having one declared or repositories to resolve it from are the most common causes

[smoky violet]

but, the url there downloads a jar just fine for me

generally I would put the paper repo above enginehub, but it's probably not searching the next repo since you are getting some other failure than a 404, sending full logs instead of snippets is useful for reasons like this

[quaint raven]

Does the setup work without enginehub and WorldEdit and WorldGuard?

[grizzled hamlet]

i managed to solve it by tweaking some stuff and deleting useless lines in settings.gradle.kts

[brave widget]

message.txt by @undone thicket: https://pastes.dev/2bapvbVKDq

[undone thicket]

@fossil topaz this is what the stacktrace is

tasks.assemble {
dependsOn(tasks.reobfJar)
}

this is all I have to do with reobf

in the build file

[grizzled river]

asked this a few days ago but i'm still having some trouble with the hangar publish plugin:

When I try to set a external download link for my project's download I get an error and I'm not sure what the error message in the stacktrace means. Do I possibly have to give a download link directly to the jar?

Stacktrace: https://github.com/BreweryTeam/BreweryX/actions/runs/12611082649/job/35146376356#step:5:186

Gradle task: https://github.com/BreweryTeam/BreweryX/blob/6f0a67843710c980de17b26727326a1522c69d04/build.gradle.kts#L251

[stoic ginkgo]

Hey all, So a lot has changed since i last made a plugin trying to get my head around paper
i'm trying to replace /restart & other defaults with my own command or disabled entirely.
loading the command from bootstrap and i get a nullpointer assuming the /restart command is trying to register because if i change the command to something else like /test the server starts and the command works.
Been going around in cycles for ages suggestions be apparated

[hardy tendon]

I believe you're using the plugin incorrectly, I don't think you're supposed to use an external URL but rather the output from the jar/shadowJar task (https://docs.papermc.io/misc/hangar-publishing#project-files)

[main mica]

You have the jar task disabled, so it fails to find the jar to publish.
Adding jar.set(tasks.shadowJar.flatMap { it.archiveFile }) to the registered platform should make it use your shadowed jar, similar to how its done here
and TIL Brewery is still maintained, nice to see after 13 years

[main mica]

Are you using a paper-plugin.yml? You can't define commands in the paper-plugin.yml.
Unless you have a specific reason for (e.g. registries), just use a normal plugin.yml instead

This is for help with build tooling though (e.g. Gradle). Your question sounds more like #paper-dev

[stoic ginkgo]

Okay thank you wasn't sure will move to the other channel,
yeah using paper-plugin.yml not sure what you mean use the normal plugin.yml only have 1 do i create it? the have the command works when i set it to test commands.registerCommands.literal("test")
server throws a nullpointer and and restarts if i set it to "restart"
both test & restart are in the paper-plugin.yml

[grizzled river]

just went back to using jar#set instead of trying to use an external link for now 👍

[soft python]

everyone, please help me with build paper 1.17.1 i need id("io.papermc.paperweight.core") version "1.2.0
but there is no such file anymore, write me a private message if anyone knows how to help me

[echo kiln]

🚧 Legacy Endpoint Removal

After two years and multiple reminders, the planned removal of legacy endpoints has been successfully completed.

Maven Repository
❌ Removed: https://papermc.io/repo/repository/maven-public/
✅ New: https://repo.papermc.io/repository/maven-public/

Downloads API
❌ Removed: https://papermc.io/api/
✅ New: https://api.papermc.io/

If your projects are still using the old endpoints, please update them to utilize the new ones.

[soft python]

Thank you, I changed the repositories but there is an error

An exception occurred applying plugin request [id: 'io.papermc.paperweight.core', version: '1.2.0']
> Failed to apply plugin 'io.papermc.paperweight.core'.
   > Command finished with 128 exit code: git -c commit.gpgsign=false -c core.safecrlf=false submodule update --init

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

changed

thanks in advance

[distant mango]

update paperweight lol

latest version

[brave widget]

https://docs.papermc.io/paper/dev/userdev

[paper kestrel]

they said above that they are trying to build paper 1.17.1.
so just upgrading paperweight might not build correctly if any of the layout/assumptions changes
(and userdev isnt relevant)

[lost peak]

could anyone help im very lost!

plugins {
    id 'java'
    id 'io.papermc.paperweight.userdev' version 'v2.0.0-beta.12'
}

group = 'de.nms'
version = '2.20.5'

repositories {
    mavenCentral()
    maven {
        name = "papermc-repo"
        url = "https://repo.papermc.io/repository/maven-public/"
    }
    maven {
        name = "sonatype"
        url = "https://oss.sonatype.org/content/groups/public/"
    }
}

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

def targetJavaVersion = 21
java {
    def javaVersion = JavaVersion.toVersion(targetJavaVersion)
    sourceCompatibility = javaVersion
    targetCompatibility = javaVersion
    if (JavaVersion.current() < javaVersion) {
        toolchain.languageVersion = JavaLanguageVersion.of(targetJavaVersion)
    }
}

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8'

    if (targetJavaVersion >= 10 || JavaVersion.current().isJava10Compatible()) {
        options.release.set(targetJavaVersion)
    }
}

processResources {
    def props = [version: version]
    inputs.properties props
    filteringCharset 'UTF-8'
    filesMatching('plugin.yml') {
        expand props
    }
}

[distant mango]

remove the v

[lost peak]

???

lienanything?

[static urchin]

The version is 2.0.0-beta.12 not v2.0.0-beta.12

[lost peak]

ohhhh

[distant mango]

also next time you probably want to give a bit of information

[lost peak]

hastebin?

or how ?

[distant mango]

no like what your issue is lol

is it fixed now that you removed the v infront of the version?

[lost peak]

uhm

Error:

https://hastebin.skyra.pw/raw/monujowave

[distant mango]

update gradle to 8.12

[lost peak]

huh? okay ig

[distant mango]

gradle/wrapper/gradle-wrapper.properties

[lost peak]

ok it worked thx!

[misty pond]

How use new dev-imports? If I use it like I used it before, I get an error::io.papermc.paperweight.PaperweightException: Failed to read library line 'minecraft net.minecraft.util.RandomSource', no library file was found.

[lament scarab]

all of the sources are already in the folder?

[bronze ember]

Dev imports is only used for libraries now

[pallid elbow]

If i've been maintaining a fork 1.21.3 and below off some very old "paper fork" paperweight test-fork or whatever that was, should I just newly fork straight off Paper repo and redo my fork that way?

because the differences are significant now with all the various build.gradles

[bronze ember]

Yes

Start clean and copy patches over and fix

[pallid elbow]

awesome

can I just bring in the patches the old root-level way or should I re-apply the old fashioned way

[pallid elbow]

This does not seem to work as it once did, how best to apply old patches from 1.21.3?

[static urchin]

Well what doesn't work like you'd expect there?
Tho why do you have a single patch that affects both api and server

[pallid elbow]

it's actually not it's nms ItemStack but IJ doesn't know better

These cannot be base-mapped like they used to

For starters it seems like the src doesn't have a main/ folder anymore

[lament scarab]

seperate source roots now

idk how it all plays out for forks due to the repo layout and that

[pallid elbow]

well i just forked Paper, but yeah I did use to have slice-api and slice-server, but those aren't apparent in the patch file anyway so it shouldn't matter

[lament scarab]

well, yea, because those where git submodules

now the layout is a bit more, interesting, as a nature of per-file patches

[pallid elbow]

euhhhh

In a fork of my own these days is it even worth having patches?

I can't see how one could organize things with per-file patches...

[lament scarab]

per file patches makes a lot more sense for us given the coverage of a whole bunch of stuff

it's also a pain as it loses a bunch of context

[pallid elbow]

right

I guess some of these do auto-remap correctly

some just do not

[pallid elbow]

Oof, if my fork is just a straight Paper fork, am I going to have constant paper-server/patches/features conflicts with patch numbers as they get added to paper whenever I update upstream?

[static urchin]

if you are a straight paper fork, you'll be having conflicts everywhere

[bronze ember]

We provide tooling for a reason

[pallid elbow]

😦 what tooling am i missing then for doing an own-fork?

[paper kestrel]

paperweight?

[proud maple]

I think there's some confusion, cause I assume you meant just being a direct downstream of paper via paperweight

[pallid elbow]

I used to use paperweight but it hasn't updated since the hardfork

[distant mango]

paperweight?

That's been getting updated

[pallid elbow]

oh the v2-fork?

[static urchin]

Yea

The beta versions

[pallid elbow]

well, gr8

thanks then

[static urchin]

Note that the layout changed a bit on the patches, but yea, the branches should give you an idea

[pallid elbow]

I've already done half my work to update to 1.21.4 so i should be able to just copy what patches the paper-fork version did

Not entirely sure how i'm gonna hard merge the -api stuff i've done yet but, we shall see

[pallid elbow]

Is this v2-fork like very beta? I've already got duplicate fork-api/server as well as paper-api/server which seems incorrect pretty much out of the gate

and/or is applyAllPatches not the correct "new" applyPatches behavior to do or something

[static urchin]

no that is intended, the fork-api folder is the source in repo for you

and paper-api iirc is the patched ignored one

[pallid elbow]

All src seems to be in paper- still

[static urchin]

well all paper source is

[pallid elbow]

the fork- ones just seem to be.. patches

[static urchin]

your own source is in fork-api

e.g. your own event types

(at least thats where they could be)

[pallid elbow]

oh for like custom brand "new" code?

[static urchin]

yea

paper-api should preferably only contain our api + the changes your fork does to those via patches

while brand new types are in fork-api so you can just have .java files there

same for fork-server and paper-server

[pallid elbow]

i'm still confused? cause for example nms ItemStack is in fork-server/src/minecraft/etc, and not paper-server

oh ok, fork-server is bukkit, paper-server is all papers' custom stuff?

[static urchin]

Yea, paper-server is our source for paper again

[pallid elbow]

goodness

one of these feels backwards...

like if fork-api is my own only brand new custom fork api stuff, so it feels that fork-server would be similar

[static urchin]

fork-server is your own stuff

it just also hosts the mojang sources

[pallid elbow]

no it's also all minecraft's stuff

[static urchin]

in a separate source set

[pallid elbow]

well

that's what feels weird

[static urchin]

I guess?

[pallid elbow]

Why they'd be intermixed like that

[static urchin]

Hmm yea, I guess the alternative would be to have paper-api and paper-server just be separate source sets in fork-api and fork-server

[pallid elbow]

Like everything "before" was paper-server/api, now, presuming I'm just updating from 1.21.3, I have to do:

• api in paper-api
• server in fork-server

[static urchin]

but I presume jmp has a good reason to structure it like that / maybe you can configure this

[pallid elbow]

I feel like this is @smoky violet ping worthy ^ (assassinate me if needed)

[static urchin]

Well you can configure the output dirs in the build.gradle.kts

But in all honesty, I have not looked at this extensively

[pallid elbow]

i'd really rather have just the one pair of folders (like before), it seems like presuming the fork- submodules as being for entirely custom stuff, while sensical, wouldn't be the default modus operandi imo

others' forks who would be extensive enough could have their own custom submodules if they need to, but i guess just presuming it is... extra

[static urchin]

but yea idk if that is feasable.
The respective paper-api and generator folders aren't just the java files so like. It would need some more work to somehow smack it into the fork-api source sets

And like, paper-server has multiple source sets for example.

[pallid elbow]

I mean I can I guess get over it it just feels incorrectly mixed

Makes remapping the base folders for bringing in patches a pain

[static urchin]

Idk if
fork-server
src
main
minecraft
paper-main
paper-test
paper-log4jPlugins
is a remotely valid layout
but yea, you have put your life on the line to ping jmp so, I am sure he can provide some more feedback/explanation

[pallid elbow]

So I guess on account of these patches i'm bring in being in fork-server, then I have no patches to generate anymore?

but because my patch touches api, then I will create a patch because it's in paper-api

Basically I brought in a patch with API/Server touching stuff, comitting it to git gives me, just this? (feels wrong)

[floral jackal]

i wanted to ask question about paperweight-examples, how to create patch from build.gradle.kts in forky-server

manually changing the patch is probably not the right thing to do

i don't understand at all

[paper kestrel]

Apply patches, change generated code, add it to the right commit /add a new one (for feature patches)
Rebuild patches

I'm pretty sure this is documented somewhere tho

[floral jackal]

it ignored by git

[lucid mulch]

the way i did it was to manually create a patch from diff between the unmodified one and the modified one but i think there is a better way

[bronze ember]

One of the rebuild tasks rebuilds that patch when you edit the actual file

[floral jackal]

found it, rebuildPaperSingleFilePatches

[light thunder]

[main mica]

Is your IntellIj up-to-date? there were some issues in older versions

[visual plank]

Pretty sure

[visual plank]

I'm assuming your build properly finds usages, then?

[north flume]

There is a 24.3.1.1

[visual plank]

Updating now...

[north flume]

No idea if it'll fix it but old intellij likes to be weird

[main mica]

I haven't updated to the new paperweight yet, so can't say

[visual plank]

Okay. Updated in IntelliJ and no change. Does anyone have this working right now? If userdev source files are downloaded, then it just seems like I need to tell IntelliJ to search for usages in that directory, no? How would I do that?

[bronze ember]

IJ doesn't index libs like that, does it?

[smoky violet]

open a paper-server file and click "attach sources" in the top

then you can select "project and libraries" when searching

[bronze ember]

That does look like the source is already attached, but I don't think that IJ indexes lib code for the find usages stuff

[smoky violet]

thats an api file

it does if sources are available

you need extra plugins which idk if they are updated for it to index libs without sources

[visual plank]

jmp would you be down to hop in a vc to see my screen?

[smoky violet]

if you have userdev setup, literally just double press shift, search for ServerPlayer or something, open it, and click attach sources

[visual plank]

I have PlayerList.java open but can't find Attach Sources.

[bronze ember]

Because they already are attached

[visual plank]

That's what I was thinking...

[smoky violet]

then when you search make sure to select 'project and libraries'

in that popup you got it's in the gear

[visual plank]

That did the trick! That's what must've changed. I set Project and Libraries to the default for usage search. Thanks!

(I had tried the whole CTRL+ALT+F7 suggestion before but it still didn't work, so I assumed setting that to the default wouldn't help. I guess I didn't do it right at first or something.)

[lucid mulch]

Hi i attempted to try and document the new patching system for forks and i made a pr to the examples repo. Any feedback would be greatly appreciated

[blazing harbor]

im trying to build with paperweight for 1.21.4, but gradle isnt really helping me out here. I dont know what I have done incorrectly, this is the error https://pastes.dev/m1JxJ10kI1, and I just have these gradle plugins ```gradle
plugins {
id 'java'
id 'io.github.goooler.shadow' version '8.1.7'
id 'io.papermc.paperweight.userdev' version '2.0.0-beta.13'
id("xyz.jpenilla.run-paper") version "2.3.1"
}

its saying something about java 17 which I dont really understand, but im using java 21 so idk where it got that idea from

[lucid mulch]

update your gradle version to 8.12

@blazing harbor

[blazing harbor]

ah alright ill try it out tomorrow, thanks

[dusty dawn]

    id 'java'
    id 'com.gradleup.shadow' version '8.3.5'
    id("io.papermc.paperweight.userdev") version "2.0.0-beta.13"

}

group = 'cc.ferrets'
version = '1.0-SNAPSHOT'

repositories {
    mavenCentral()
    maven {
        name = "papermc-repo"
        url = "https://repo.papermc.io/repository/maven-public/"
    }
    maven {
        name = "sonatype"
        url = "https://oss.sonatype.org/content/groups/public/"
    }
    maven {
        name = "CodeMC"
        url = uri("https://repo.codemc.io/repository/maven-public/")
    }
    maven {
        url = url("https://maven.enginehub.org/repo/")}
}

dependencies {
    compileOnly("io.papermc.paper:paper-api:1.21.4-R0.1-SNAPSHOT")
    implementation("de.tr7zw:item-nbt-api:2.14.1")
    paperweight.paperDevBundle("1.21.4-R0.1-SNAPSHOT")
    compileOnly 'com.sk89q.worldguard:worldguard-bukkit:7.0.13'
}

def targetJavaVersion = 21
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(targetJavaVersion)
    }
    sourceCompatibility = JavaVersion.toVersion(targetJavaVersion)
    targetCompatibility = JavaVersion.toVersion(targetJavaVersion)
}

tasks.withType(JavaCompile).configureEach {
    options.encoding = 'UTF-8'
    options.release.set(targetJavaVersion)
}

processResources {
    def props = [version: version]
    inputs.properties(props)
    filteringCharset 'UTF-8'
    filesMatching('paper-plugin.yml') {
        expand props
    }
}

// Updated shadowJar configuration
tasks.named('shadowJar').configure {
    archiveClassifier.set('')
    configurations = [project.configurations.runtimeClasspath]
    relocate("de.tr7zw.changeme.nbtapi", "cc.ferrets.ferret_God.nbtapi")
}

tasks.named('build').configure {
    dependsOn 'shadowJar'
}

tasks.named('jar').configure {
    finalizedBy 'copyJar'
}

task copyJar(type: Copy) {
    from(tasks.named('shadowJar'))
    into("/home/SharedFiles/IdeaProjects/Ferret_God/Minecraft_Test_Sever/plugins")
}```

> io.papermc.paperweight.PaperweightException: Unable to resolve a dev bundle, which is required for paperweight to function.

* Try:
> 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).
> Run with --scan to get full insights.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
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/8.12/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.```

[barren grail]

Remove the compileOnly paper-api dependency (as per this) and try if that fixes it

[dusty dawn]

it still doesnt work

oh i think i know why it broke

never mind

    implementation("de.tr7zw:item-nbt-api:2.14.1")
    paperweight.paperDevBundle("1.21.4-R0.1-SNAPSHOT")
    compileOnly ("com.sk89q.worldguard:worldguard-bukkit:7.0.13")
}```

* What went wrong:
A problem occurred configuring root project 'Ferret_God'.
> io.papermc.paperweight.PaperweightException: Unable to resolve a dev bundle, which is required for paperweight to function.

* Try:
> 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).

CONFIGURE FAILED in 4s

[main mica]

accidentally in gradle offline mode or something?

[dusty dawn]

how do i check

[main mica]

in IntelliJ its one of the buttons in the top right above the gradle tasks

[barren grail]

that one

[dusty dawn]

lol its ofline

💀

👍

[wind slate]

hey, i seem to be struggling getting the 1.20.4 paperdevbundle
here's my build.gradle:
https://paste.learnspigot.com/hotifavocu.gradle
gradle 8.12
NovaPrisons:main: Could not resolve io.papermc.paper:paper-server:userdev-1.20.4-R0.1-SNAPSHOT.

[distant mango]

can you send the full log

also, remove line 59

[wind slate]

removed that, managed to fix it by clearing cache

[floral jackal]

trying to compile server jar with createMojmapPaperclipJar gives me that:

> Could not find namespace "mojang" in provided tiny tree

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
``` how to fix this

[pallid elbow]

Back on this this morning, this does seem to be wrong, .gitignore has /fork-api/src/minecraft ignored except that's exactly where I'm making changes. Is this an actual mistake?

[static urchin]

no

the minecraft source set is not checked into git

that is patched with the patches in minecraft-patches

[pallid elbow]

Well how am I supposed to commit server changes to my fork?

[static urchin]

fork-server/src/minecraft/java is a git repo

[pallid elbow]

I am deeply confused

As in, I don't know what to do then

[static urchin]

you cd into there, commit, and rebuild patches

thats like, the old paper-server dir, just this time only for mojang stuff

[pallid elbow]

Is there a way to do that in IJ? in a... git submodule or whatever?

[static urchin]

uh, idk but I also don't use intellijs commit stuff

there may be a gradle task to fixup stuff if that is what you are doing

[pallid elbow]

And so this means you have to maintain two wholly separate git commit situations? or I guess API doesn't do patches or whatever

[static urchin]

Yes, you maintain both a git repo for mojang changes and a git repo for paper changes

[pallid elbow]

Lord this got complicated

[static urchin]

Well, this is kinda the only way given the source sets are now split up in our repo too

You could I guess do a simplistic af approach and just merge the two, but then you loose all the speed you gain by having source in repo on our end, so that isn't what patcher does.

[pallid elbow]

do i rebuildAllServerPatches from root? That didn't generate a patch

i lied

[static urchin]

[pallid elbow]

I would wager in IJ there's probably a way to include the src/minecraft's git situation

[static urchin]

oh there is yes

100%

[pallid elbow]

I've been able to practically exclusively use IJ for all commits, conflict resolves, etc in the before times

[static urchin]

add it as a git source root and life is good

Settings > Version Control > Directory Mappings

[pallid elbow]

ok i shall try on Patch Number Two

hmmm

i think that committed to the wrong git

oh

paper-patches and also minecraft-patches

but it worked

Checking this into here doesn't seem to survive rebuild/apply patches

[static urchin]

did you rebuild api patches?

[pallid elbow]

well

no

[static urchin]

but appliedAllPatches I presume

[pallid elbow]

i did rebuildAllServerPatches

[static urchin]

mhm

[pallid elbow]

[static urchin]

but that file should 100% be in your source-in-repo folder

not in the paper one

[pallid elbow]

does it make a real difference?

[static urchin]

Well, you have source in repo

[pallid elbow]

having to reconstruct file structure sounds like fun for all api additions 😦

[static urchin]

so you don't need to rebuild api patches when you edit this

no cd'ing into the folder

[pallid elbow]

no cd now that i added the git source root in IJ fwiw

[static urchin]

Or that

[pallid elbow]

but... fiinneee

[static urchin]

but like, types that you add sound a lot nicer to just be in repo xD

[pallid elbow]

yes it's i suppose fair it's just so bleh having there be all this "Custom to my fork" stuff in fork-api, but all of the meat in the paper-server mess

i don't know a better way you'd do it but yeah

[static urchin]

Well the old way you can still do if you wanna

[pallid elbow]

like only half the shit gets to be organized

[static urchin]

tho you'll always have the split between paper-server and mojang, just because pw needs to do different things for the two source sets

[pallid elbow]

indeed

to do this "correctly" does add quite a lot of overhead for a fork dev

there's not a lot of attraction to the new way

[static urchin]

¯_(ツ)_/¯

fork devs are capable of writing their own tooling if they wanna I guess

[main mica]

if there is some docs available, maybe

[static urchin]

But like, the only actual downside to the previous approach is the fact that you now have three git repos I guess

[pallid elbow]

I mean big thanks for patiently walking through this with me lynx but god save any old fork dev who's not up paper folks' ass with questions

or IOW, v2-fork repo could use some docs

[static urchin]

with the upside of shit being faster, people getting source in repo for their own stuff etc

Well, documenting forking us is like, at the very end of our prio list

[pallid elbow]

like "Welcome to hard fork devving, forget mostly everything you know"

of course

also y no rebuildAllAPIPatches 😦

This is basically what i'm gonna run over and over: ./gradlew rebuildPaperApiFeaturePatches && ./gradlew rebuildPaperApiFilePatches && ./gradlew rebuildAllServerPatches && ./gradlew applyAllPatches

[static urchin]

might be something worth adding on the API end? I don't think there is a limitation in what API parts are rebuild

I recall jmp not wanting a rebuildAllPatches because that is a fucking hammer and needs to do a lot

[pallid elbow]

When you touch a lot of parts of minecraft with a feature change, i don't really want to have to keep deciding which of four different kinds of "patch rebuilds" i need to do

this is a problem of scale i guess

[static urchin]

Well, that is again only solved by consolidating all incoming source sets

which looses out on a lot of speed and isn't in patcher for that reason

like, if you wanna have a single directory for -api and for -server, you just go back to old slow land

[main mica]

old speed was perfectly fine for me tbh

I would rather have that than four rebuilds every time

[static urchin]

Can open a feature request for that I guess? Idk if jmp cares to maintain that.

[bronze ember]

Generally, paperweight patcher is provided as a best effort. Forks will always be a niche and never a focus for us, we only really provide it for our own needs at folia and private projects, so idk how much interest there is in supporting alternative ways of using it

Don't wanna speak for jmp tho and it's def worth opening a proposal explaining how stuff would work

[main mica]

that requires understanding how stuff currently works, which I tbh haven't fully

[pallid elbow]

v2-fork is also beta right? so I think we're still trailblazing basically

[pallid elbow]

More or less i think my angle is that of UX and ease of use, right now it is at its first stage of "this is how we know to use it presently"

[static urchin]

eh kinda? I don't think jmp had any large changes planned

[pallid elbow]

and my complaints are really suggestions of UX improvements

technically my beef doesn't require change

perhaps adding applyAllAPIPatches would be useful but, whatever i guess

[brisk belfry]

Hm. I always thought you provide it because you want to make forking paper as easy as possible for other people. And to encourage people more to create their own fork for personal use/redistribution.

[static urchin]

No, definitely not as easy as possible.

Its there because a lot of the code paperweight has to do for us is code that needs to happen for forks, so its easier to implementing forking in there than some third party tool.

[bleak lark]

how do you guys support multiple versions of the dev bundle in a single plugin?

[bronze ember]

Using it in multiple modules should work

Add the plugin to the root with apply false

[bleak lark]

so multiple modules, one i guess is the "Base" Module, which implements all the version modules?
and on the main build gradle i build the uber jar?

[bronze ember]

yes

idk if we have a good exmaple repo of that

[bleak lark]

I will try to do it in a new Project, if it works, i can publish it for others to look @

small success = better,
thats why i will do on empty project with plugin that only prints a message based on the nms?

[bleak lark]

what version do you recommend i have in Base/Core?

[bronze ember]

latest

it can read older dev bundles

[thorny dirge]

Unable to resolve a dev bundle, which is required for paperweight to function.

how to fix this

[distant mango]

noww do the 2 other things I asked

[thorny dirge]

https://pastes.dev/GjyC8ZjmE5

[distant mango]

and the build logs

also update the shadow plugin to https://plugins.gradle.org/plugin/com.gradleup.shadow

[wanton horizon]

I'm still having issues updating paperweight to v2. I keep getting this error:

Could not create task of type 'UserdevSetupTask'.
Configuration with name 'decompiler' not found.

In the documentation there is no mention of a decompiler configuration? This is the repo I'm updating: https://github.com/ChimpGamer/Hyperverse.
All I did was bump the paperweight version.

[bronze ember]

pls dont cut logs

share the full log as a paste

[wanton horizon]

https://pastebin.com/gTpyRqGQ

[bronze ember]

dont people generally add paperweight to the root with apply false?

[smoky violet]

you should

but since they aren't reusing dev bundles across projects it won't error

it will just load paperweight classes multiple times for no reason

something in their build config is causing the setup task to get realized immediately afaict

you can try the snapshot once this builds https://github.com/PaperMC/paperweight/commit/c38eef616b35b395b527a24fbcec1bd1bcda0fdb

but also you should do what mini said, and find out what is causing stuff to be eagerly realized

it's likely hurting your overall build performance

[wanton horizon]

I should use 2.0.0-SNAPSHOT as version to get that build when it is done right?

[smoky violet]

yes, you will need the paper repo in your pluginManagement.repositories of settings

if you are creating the repositories block then make sure to add gradlePluginPortal() above paper

[wanton horizon]

Yep got it. Seems to work!

[smoky violet]

I don't see anything obvious that would cause the task to be realized immediately in your build

I hope it's not something in cloud-build-logic

[bleak lark]

thanks it works! i did minimal gradle setup for it, i will put it in github for others to use, also i would like some critique

[wanton horizon]

Seems I'm having trouble again but now with javadoc task

Execution failed for task ':hyperverse-nms-1-21-4:javadoc'.
> Javadoc generation failed. Generated Javadoc options file (useful for troubleshooting): 'C:\Development\Projects\GitHub\Hyperverse\hyperverse-nms-1-21-4\build\tmp\javadoc\javadoc.options'

* 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 12s
16 actionable tasks: 1 executed, 15 up-to-date

[bronze ember]

And you didn't bring the full log again 🙂

[wanton horizon]

That's the IntelliJ build console ouput

This is when running with --stacktrace https://pastebin.com/2iGPXrxa

[bronze ember]

There is no log above that?

In IJ, in the tree in the output, select the root node

Not the leaf

[wanton horizon]

https://pastebin.com/v4v0eHA5

[bronze ember]

That looks like wrong java version

[wanton horizon]

Really? I was able to compile all just fine before updating paperweight.
Toolchain is set to 21.

[lament scarab]

Wrong person;

[lament scarab]

Update to the latest build of java 21, that was fixed in 21.0.3 iirc

[smoky violet]

supporting old versions isn't something we really want to encourage, but it is a feture of paperweight and I need to test it

so I've pushed this https://github.com/PaperMC/paperweight-test-plugin/tree/multi-project

[floral jackal]

I ask again, what does this error mean: Could not find namespace "mojang" in provided tiny tree
i got this when running createMojmapPaperclipJar

i do not understand the essence of the error

[smoky violet]

you have some sort of version mismatch going on

[bleak lark]

that's awesome!

[grim mauve]

me trying to figure out how to update a Paper fork to 1.21.4 (i'm cooked)

probably I will need to see all of Cryptite's messages on this channel to see how he did things, because it seems like he was just as confused like I'm right now

[rapid fractal]

just search jmp's message when he helped others.

so you skips all the runaround

[faint hill]

Hey hey, I asked earlier in paper-dev, and Machine Maker pointed me here if I was confused. I'm trying to convert our feature patches to file patches, as that would be 100% easier to manage going forward. I'm trying to do this with our API patches first, as they have a lot of the annoying bits to them, but after they apply, I'm not too sure what to do next. I tried soft resetting, but I think I may be doing it wrong? Would I just cd paper-api and then git reset --soft HEAD~1? and then ... ?

[barren grail]

More of a "gradle/intellij" question but figured this was the best channel for it on this server, does anyone happen to know a way of specifying a custom "action/signal" intellij should send to gradle to "stop" a build? In this case specifically for gracefully stopping a testserver instead of just killing it instantly

[inland topaz]

Hey, I am running into issues with setting up a fork-of-fork. It seems like its selecting the wrong directory for my upstream fork. .gradle/caches/paperweight/upstreams/fork/.git doesnt exist but .gradle/caches/paperweight/upstreams/folia/.git does.

https://paste.t-ch.net/DI8N6TnvHBhSDcP#L46

[lucid mulch]

can you send your build.gradle.kts file?

[inland topaz]

Absolutely
https://paste.t-ch.net/mVewyK3uzo0VIyc

[lucid mulch]

yea the root file looks fine, are you sure you patched the server one correctly?

https://github.com/PaperMC/paperweight-examples/blob/v2-fork-of-fork/forky-server/build.gradle.kts.patch

like replacing fork with your fork’s name

[inland topaz]

Server one was not patched correctly, thank you much. I forgot a change

-       rootDirectory = upstreamsDirectory().map { it.dir("fork") }
+       rootDirectory = upstreamsDirectory().map { it.dir("folia") }

[grim mauve]

one thing that I don't get it yet

how Paper knows when to create a file patch, and when to create a feature patch?

[lament scarab]

it just uses the git tree

[static urchin]

file patches are derived from the files tagged commit

[lament scarab]

all of the file patches are in a single commit

[static urchin]

all commits above that are feature patches

[grim mauve]

oh

another thing: if I want to edit the build.gradle.kts, it must be a file patch right?

[static urchin]

build.gradle.kts is special it has its own patch file

[grim mauve]

I noticed that because even if I edit a build.gradle.kts in a feature patch, the build.gradle.kts is evaluated before the feature patches are applied

[static urchin]

Yea, from what I understand, no feature patches for the build.gradle.kts file

Tho that should be semi fine, that file should have minimal changes

[grim mauve]

I think I'm stupid and I don't know how to update 1.21.3 patches to 1.21.4

is fork-server/src Minecraft sources, and paper-server Paper sources?

[static urchin]

not easily

[grim mauve]

because if I apply patches to paper-server and rebuild the patches, only the Paper changes seems to be created in the features folder

[static urchin]

fork-server/src/main is your own types
fork-server/src/mojang is mojang types
fork-server/src/paper is paper types

[grim mauve]

am I doing something wrong then

[static urchin]

Well what "non paper changes" are you applying to paper-server

that you'd expect in a feature patch

[grim mauve]

because mine only has fork-server/src/ (own types), fork-server/minecraft/ (has the server source code including Paper things) and paper-server (also has the server source code)

[static urchin]

fork-server/minecraft should have our patched minecraft things

paper-server should have our types like CB

like, previously you had two git dirs you'd mess around with, the api and the server one.
Now you have the api one, the mojang types and the paper types, so three dirs

[grim mauve]

now that I have noticed that paper-server only seems to have the "Paper types"

[static urchin]

That. That dir is basically our "in repo files"

which is why it is separated from the mojang dir now

[grim mauve]

so let's suppose I want to edit and patch MinecraftServer, how could I do that?

(the MinecraftServer.java file)

if I edit fork-server/minecraft/.../MinecraftServer.java

when I try commiting it...

$ git add minecraft/java/net/minecraft/server/MinecraftServer.java
The following paths are ignored by one of your .gitignore files:
fork-server/src/minecraft
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

[static urchin]

the fork-server/minecraft/java dir is a git repo

[grim mauve]

oh

[static urchin]

so is paper-server/java

[grim mauve]

so I commit and ./gradlew rebuildMinecraftPatches

[static urchin]

There you go xD

so yea, that would be a feature patch

if you want file patches (not that I'd recommend them much) you'd fixup into the file commit in that git repo

[grim mauve]

so if I want to edit Paper files, I need to edit them in paper-server

and use rebuildServerPatches

[static urchin]

Yea

[grim mauve]

I don't get why paper-server is on the root directory instead of working like the minecraft source set tho

[static urchin]

would be annoying as fuck to split up the actual source sets of paper-server

it includes tests and the log4j plugin

[grim mauve]

[static urchin]

mojang is just the source/main source set so yea, thats easy

no idea if we could expose an option to like, move up the mojang sources to make it consistent

but the dependency and source set fuckery patcher has to do is already a lot

[grim mauve]

maybe the folder naming could be different because when I think about "paper-server" I think "oh the Paper™️ server including NMS + other things"

that's why I was confused

[static urchin]

Yea, it honestly might just be something people have to get used to

in the end, its fork development. A bit of a learning curve is perfectly fine if it saves us a lot of work on patcher

[grim mauve]

by the way, if I understood correctly, the "minecraft" source set can access the "paper-server" files, and "paper-server" can access the "minecraft" source set

so "paper-server" does not have "minecraft" as a dependency, in reality it is like if you copied and pasted the "paper-server" into the "minecraft" folder and vice-versa

(now that I've noticed that the fork-server build.gradle.kts specifies paper-server as a source set so now it makes sense why it works like that, so in reality fork-server source code is minecraft (Minecraft Server source code + applied patches) + main (fork files) + root paper-server (Paper files))

[static urchin]

Yea, source set fuckery

[grim mauve]

and I guess that the advantage of doing this like that, is that I don't need to create a .patch file for things that aren't editing Minecraft Server/Paper files (so if I create a config file for my fork, that doesn't need to be inside a .patch file)

[barren grail]

You only need patches for minecraft files, paper (api) changes can be committed directly

[static urchin]

Yea, that is the goal

no, this is fork development. paper-api changes are patches

[barren grail]

no?

riight, fork stuff

[static urchin]

but yea, any type you create can be in repo

but this is also the most sane way for patcher to do it, just because of how our repo looks now.
Otherwise patcher would have to like, merge our in-repo sources and the patched minecraft sources and shit

[grim mauve]

lynx's POV: lynx trying to help a poor fork dev that is trying to update their 1.21.3 fork to Paper™️ 1.21.4 post-hard fork®️ https://media.tenor.com/bT69cQ-IoTgAAAAe/popteamepic-doesn't-get-it.png

[crude kernel]

adding kotlin to paper is so incredibly based

[static urchin]

[grim mauve]

kotlin my beloved

[static urchin]

I regret wasting my time on explaining patcher to you

your fork should have died

[grim mauve]

but kotlinx.serialization

[static urchin]

I feel cheated into supporting a kotlin enjoyer

life is worthless

[grim mauve]

but

[static urchin]

but yea xD That layout looks good

extract as much as you can into your own files

[grim mauve]

the hard part is now updating every other patch file to the new system

[static urchin]

you can look into per-file patches, tho those are a bit more annoying to update I'd presume

[grim mauve]

I wonder if there's a way to programatically check if the file is in paper-server, or in minecraft source set, or if it is a brand new file, and split it up automatically in different patches (or a brand new file)

I mean technically it can be possible

[static urchin]

sounds pretty scuffed xD ¯_(ツ)_/¯

[grim mauve]

true

but if it ain’t gonna be scuffed then where’s the fun in that

[bronze willow]

I just want to double check because im a bit confused, could i theoretically just copy the v2-fork-of-fork-branch and i have a fork of a fork? And where do i modify the fork repo? Or where does the repo get the fork data from?

or is this the fork ref?

repo = github("PaperMC", "paperweight-examples")
ref = providers.gradleProperty("forkRef")

[lament scarab]

forkRef is a gradle properly

[bronze willow]

Would that be the data of the fork of paper? So if im forking purpur its github("PurpurMC", "Purpur")?

[lament scarab]

that would be the commit hash you want the thing to checkout from the fork repo

if that's their gradle org/repo name, yes

[bronze willow]

Okay thx

Then i did something very wrong before, because i was just cloning their repo

And how can i modify this patch? https://github.com/PaperMC/paperweight-examples/blob/d2022b4721f785bf2aa6f8e6cbe2fbac09c5c5bb/forky-server/build.gradle.kts.patch

[lucid mulch]

You modify the build.gradle.kts file and rebuild it using ./gradlew rebuildPaperSingleFilePatches

[bronze willow]

And the file is get automatically?

[lucid mulch]

yes

[bronze willow]

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

io.papermc.paperweight.PaperweightException: Command finished with 128 exit code: git -c commit.gpgsign=false -c core.safecrlf=false reset --hard base

What happend here?

[brave widget]

message.txt by @bronze willow: https://pastes.dev/ffJUc6RAr8

[lament scarab]

update paperweight

outside of that, check paths, etc

[bronze willow]

So the example is not up to date

[static urchin]

Indeed, we do not update our examples on the ever moving beta targets

[lament scarab]

the repo is using the latest version though

sooo

[static urchin]

Can also run with -Dpaperweight.debug=true

[brave widget]

message.txt by @bronze willow: https://pastes.dev/HBQqDqlbEr

[bronze willow]

So the ref is wrong?

[lament scarab]

Filename too long

[bronze willow]

Why?

[static urchin]

average windows L

[lament scarab]

Because you're on a crap OS

either use a shorter path or configure long path support in your OS

[static urchin]

|| Or switch to a proper OS ||

[bronze willow]

But the path is from paper, right?

[main mica]

or just use WSL, its more sane for this stuff anyways

[lament scarab]

it's files on the disk

the path is relative to whatever folder you're running repo in

[main mica]

Well technically paperweight could opt-in to long_paths itself

[lament scarab]

and windows default file limitations are strict as heck

it can't

[bronze willow]

I dont even have a src folder in the root

error: unable to create file src/main/java/io/papermc/paper/command/brigadier/argument/resolvers/selector/EntitySelectorArgumentResolver.java: Filename too long This file does not exists in the root

[lament scarab]

No, because the git command is ran insode of a different folder, as is indicated in the logs

[bronze willow]

Im just using wsl now

And it seems to work

[main mica]

yeah it does not have that limitation

[static urchin]

thank god for normal OS

[main mica]

But I don't see why paperweight couldn't? Paths prefixed with \\?\ ignore the limit

[static urchin]

Obviously it isn't our job to fix people using shitty operating systems

[main mica]

You can also opt-in via the manifest, but I guess thats something on the gradle side of things

[static urchin]

not that windows is a smart move outside of the path limit anyway

[lament scarab]

paperweight is a tool which invokes external software

you'll note that the thing that shit the bed here was git

[bronze willow]

Is that normal?

[lament scarab]

Maybe there is some bastardised way of working around it, but, pretty much nobody on the team uses windows

[main mica]

Yeah but it has core.longpaths option too?

[lament scarab]

Yes, which requires a registry flag to be tweaked

git itself would need to deal with the manifest changes required in order to mitigate the need for that config option

[main mica]

It does not? well thats stupid then

Yeah seems like they don't do it because older Windows versions didn't support it properly, that sucks

[brave widget]

message.txt by @bronze willow: https://pastes.dev/bpIUoeNFYK

[bronze willow]

Do i need to include it in the settings.gradle.kts?

[lucid mulch]

remove the build.gradle.kts files in the server and api dirs and try again

(keep the .patch ones tho)

[lament scarab]

No, you need to modify the build.gradle.kts to point to your own api submodule instead of the forks

[bronze willow]

Oh

yeah true

[lament scarab]

at least, not familiar with this thing, just a 2 second guess from the error

[lucid mulch]

Im curious why does the build.gradle.kts file have to be patched? couldnt it just be left as a normal file?

[lament scarab]

because people make changes over the top of others

[bronze willow]

forky-server should have implementation(project(":forky-api")) but when i apply the patches the forky-server gets replaced by purpur-server

Patch /mnt/c/.all/.projects/.varilx/vax-spigot/forky-server/build.gradle.kts.patch failed:
[WARN] Missing patch target for purpur-server/build.gradle.kts.patch

Patch /mnt/c/.all/.projects/.varilx/vax-spigot/forky-api/build.gradle.kts.patch failed:
[WARN] Missing patch target for purpur-api/build.gradle.kts.patch

Somehow i get this error

But why?

[gilded obsidian]

Hey, does anyone know a good tutorial (can be text or video) on how to install/set up paperweight-userdev? I'm to those kind of stuff

[static urchin]

https://github.com/PaperMC/paperweight-test-plugin

[gilded obsidian]

I saw this but isn't it for 1.20.5? I needed to 1.16.5...

[static urchin]

[lament scarab]

1.16.5 was pre paperweight

you'd need to manually install that version to your own local maven repo or something by cloning the repo from git or seeing the pin in #paper-dev

you are generally on your own, however

[gentle viper]

Why does this happen? A fix that someone posted was to delete paper-server and paper-api dirs which does work, but I'd rather it not happen at all

[lament scarab]

generally as patches weren't applied

[gentle viper]

so if patching fails then this can happen

[lament scarab]

well, paperweight needs to load the project up and do stuff to properly have the dependencies it needs for tasks

so, either the patches weren't applied, or, something went sideways

very hard to say with a 0 context screenshot

[coarse ginkgo]

ideally, is my fork should be compilable without feature patches? and at least work like its upstream

[lament scarab]

your fork can work however you need it to work

We like the idea of being runnable without feature patches cos our feature patches are the big chonky things that we might need to wait to update and want to continue without waiting for them

but, being able to run without having the feature patches would probably be nice so you can easily navigate that as a step before you move onto the big chonky stuff

[grim mauve]

me reading this after throwing everything into feature patches

[static urchin]

having everything as feature patches can also be nice

Especially around updating your upstream

per-file patches can only emit .rej files on failure

while feature patches iirc shouild be able to emit 3way

[smoky violet]

converting feature -> file is dead simple

the other way around not so much

[static urchin]

that too

[grim mauve]

now I found out why Paper took a bit to finish the "hard forking" process, every patch that I try to apply fails because something somewhere somehow got renamed

[static urchin]

yup xD

enjoy the variable/parameter renames that don't fail to apply

[smoky violet]

we should have switched to parchment earlier

[bronze willow]

• What went wrong:
  A problem occurred configuring project ':forky-server'.

Cannot query the value of property 'outputDir' because it has no value available.
erm

What does has no value avaiable mean?

[bronze ember]

Don't crop errors, show the full log with stacktraces

[bronze willow]

I copy/pastes wrongly sorry

[smoky violet]

it means you have an invalid build config

there is no value because you didn't set one

[faint hill]

what's the difference in paper-patches and minecraft-patches for the server? assuming paper-patches applies to paper-server and minecraft-patches applies to fork-server?

And if that's the case, do I need to sort by patches into each/break them up into multiple patch files?

[smoky violet]

to fork-server/src/minecraft/<java/resources>, yes

[bronze willow]

I just copied the example stuff

[brave widget]

message.txt by @bronze willow: https://pastes.dev/JR5Pxa9DpH

[smoky violet]

well, the example branches apply and build

so either you didn't just copy it or you copied it wrong

[bronze willow]

Probably i coppied it wrong, can you still help me based on the error?

[smoky violet]

that looks like a different error than the one you mentioned earlier

[bronze willow]

Yeah thats true

[smoky violet]

importing library files happens before applying patches

you probably have two forks using the same work dirs somehow

send your build files in pastes

or link gh

[bronze willow]

https://github.com/Knerio/test-fork-of-fork

[smoky violet]

you’re not editing the purpur fork config

look again at the forky build file patch

-server

[bronze willow]

Do i need to change this?

[smoky violet]

it's editing upstreams ForkConfig

[bronze willow]

i dont understand

Do you mean this?

[void hill]

Changed versions in my modules from 2.1.4 > 2.1.5 but somehow got a dependency issue between modules? I shade them.

[bronze willow]

It works now

haha

[smoky violet]

are you crossing fs boundaries or something

that is pretty slow

[bronze willow]

what are fs boundaries

[smoky violet]

like, running it in windows while the files are on a wsl disk

dev drive should be ok

[bronze willow]

Im on windows using wsl because of this

[smoky violet]

but really want to avoid crossing over for best performance, if the files are in wsl run gradle in wsl

whats your specs

even github actions only takes 8 mins to apply and build

[lament scarab]

what's your pwd?

[bronze willow]

my what?

[lament scarab]

run pwd

[lament scarab]

so, yes, you're crossing fs boundaries

[smoky violet]

just the opposite direction to what I described

[bronze willow]

Soooo what does that mean?

[lament scarab]

it means that it's having to run over to the windows filesystem to do stuff

[smoky violet]

^

and vice versa

[lament scarab]

which is basically a networked filesystem, which is slow

[bronze willow]

But i cant run gradle on windows

[lament scarab]

keep stuff inside of the wsl filesystem, i.e. in your home folder in there

[bronze willow]

And how do i get it there? Clone it again?

[lament scarab]

Ideally, yes

[bronze willow]

And how can i access that via intellij?

[lament scarab]

though, if you cloned the repo in wsl you can just move it

point IJ into the wsl filesystem

[bronze willow]

Whats my wsl home path?

[lament scarab]

it will see that it's WSL and do some magic, iirc

/home/yourname inside of wsl

[bronze willow]

this?

[lament scarab]

i.e. the default folder when you login to wsl

yes

[bronze willow]

Could i do that?

[lament scarab]

.

if you cloned it in windows and then open it in linux, you can have some issues

[bronze willow]

Ill just clone

But is my intellij now slower because of running it in wsl?

In a fresh installation

So now i modified something in fork-server/src/minecraft/ and i used ./gradlew rebuildAllServerPatches, but now all i get is the paperassesroot thingy

[smoky violet]

you can ignore that file

you need to actually commit your changes though

[bronze willow]

And where do i put my api changes? In my forky-api?

Because that whole folder is empty

[smoky violet]

the example includes patches to the api as well

[bronze willow]

Where?

https://github.com/PaperMC/paperweight-examples/tree/v2-fork-of-fork/forky-api
This folder is also empty

[smoky violet]

look at the v2-fork branch

[bronze willow]

So completly new files are just files and patches are patches?

[smoky violet]

yes, like in paper, it's a good idea to familiarize yourself with the new paper structure before trying to fork

forks are an extension of paper

[bronze willow]

One last question, why is my patch an feature patch and this is an file patch?

[smoky violet]

look at the git log in paper-api

[bronze willow]

How

Is it this

And why do i need to look in that

[bronze ember]

...

The commits

[bronze ember]

The way you organize your commits matter, everything in the file patches commit ends up being a file patch

Everything else will be a feature patch

Have you actually read the contributing.md?