Missing compile time sources
I went in and split my Server Side annotation processor to a shared one to mount to my client side implementation due to shared sources.
It seems configured decently but for some reason it tells me unknown classes even though intelij shows them just right.
137 Replies
⌛ This post has been reserved for your question.
Hey @Hype_the_Time (PING ON REPLY)! Please useTIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here./closeor theClose Postbutton above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 300 minutes of inactivity.
Where are both classes? Are they in the same source folder?
and why do you use the backtick syntax in the import in the right image?
data isn't a reserved word AFAIK
and can you show the full output?kotlinpoet is doing that. no clue why.
due to enum limits in case of amounts they are being split into chunks which are then pulled into a combined class using auto generated methods
the chunks appear to be missing the NeuRepoManager for example.
the NeuRepomanager is located at
de.hype.bingonet.shared.compilation.sbenums.NeuRepoManager
or /home/spieler/IdeaProjects/BingoNet/shared-annotation-processor/src/main/java/de/hype/bingonet/shared/compilation/sbenums/NeuRepoManager.kt
the SkyblockItemsChunk are located at ?de.hype.bingonet.shared.compilation.sbenums.SkyblockItemsChunk[Number]
or /home/spieler/IdeaProjects/BingoNet/common/build/generated/ksp/main/kotlin/de/hype/bingonet/shared/compilation/sbenums/SkyblockItemsChunk[Number].ktI did a gradle clean once which caused a maybe smaller error set:
fabric:compileKotlin was cuasing a could not find class error duing compilation for the class de.hype.bingonet.shared.constants.Collections in the common sub project.
the missing class was NeuRepoManager from the shared-annotation-rpcoessor
oh so it happens in generated code?
I did a gradle clean once which caused a maybe smaller error set:
fabric:compileKotlin was cuasing a could not find class error duing compilation for the class de.hype.bingonet.shared.constants.Collections in the common sub project.
the missing class was NeuRepoManager from the shared-annotation-rpcoessor
Is there a dependency from BingoNet/common to BingoNet/shared-annotation-processor?
yes
Like an actual
implementation dependency, not just kapt
Can you show it?implementation(project(":shared-annotation-processor"))
ksp(project(":shared-annotation-processor"))
https://cdn.discordapp.com/attachments/1380852891828617379/1380852893384704140/common.build.gradle?ex=684562f8&is=68441178&hm=c6bb42f562f2afaa6f20f9ba3b6c1c9a3170c531a6c0b5c568860a97c9c9663f&
That's a git error. Can you reproducing it on a project without any of that stuff?
oh its cut off way bnefore 1sec
Can you create a new minimal project that only reproduces that issue and doesn't do anything else?
the project is quite big and theres like 3 sub projects that require each other nen stuff
reproduce it on a different project?
Without any of the fabric or groovy stuff
i mean i coudldc heck if it still works server side
will need to fix some other compile errors before by commenting out a bunch of code. ill start working on it
Is there a dependency from shared to shared-annotation-processor?
essentially.
theres the server and the client project.
shared (and shared-annotation-prcoessor) are mounted in a way that they are 1:1 same between client and server
common and fabric exist because there technically also is forge. fabric and forge extend common. (common does not use mc directley and use some frameworks that fabric gives it but i do have some other code implementation than just framework too.)
Can you show the build.gradle of the shared project?
shared is a sub folder of common in the client.
I meant common, yes
ok so that has the dependency as well
i uploaded all files in first message
Is
NeuRepoManager generated?one of them is a .kts which i uploaded agin messga e below
no
the NeuRepomanager is located at de.hype.bingonet.shared.compilation.sbenums.NeuRepoManager
or /home/spieler/IdeaProjects/BingoNet/shared-annotation-processor/src/main/java/de/hype/bingonet/shared/compilation/sbenums/NeuRepoManager.kt
Can you show your
Collections.kt?And you got that from executing
gradle clean build?i did a clean and then reran the launch task.
this time i made sure to run clean build. it seems like the same errors but a different log output.
Task :fabric:compileKotlin FAILED[Incubating] Problems report is available at: file:///home/spieler/IdeaProjects/BingoNet/build/reports/problems/problems-report.html 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. 44 actionable tasks: 37 executed, 7 up-to-date e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:3:52 Unresolved reference 'NeuRepoManager'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:4:60 Unresolved reference 'MinionRepoManager'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:5:60 Unresolved reference 'MinionType'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:271:16 Unresolved reference 'NeuRepoManager'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:271:16 Return type mismatch: expected 'NEUItem', actual 'MatchGroup'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:274:26 Unresolved reference 'MinionType'. e: file:///home/spieler/IdeaProjects/BingoNet/common/src/main/kotlin/de/hype/bingonet/shared/constants/Collections.kt:276:16 Unresolved reference 'MinionRepoManager'. ... (at the end repost cus cut off)
Can you show the full output of that?
nopt just the errors
i mean above is the full
in what way?
that one?
yes
Ah Discord doesn't show everything in maximized mode
but discord cuts it off after a certain amount. you have to download and open it or sth
its annoying me too
What is the content of
/home/spieler/IdeaProjects/BingoNet/shared-annotation-processor/build?.gradle?
There should be a build directory - not the .gradle directory
which sub dir?
Which subdirectories are there?
Anyone named classes or similar?
neurepomanager is in there
classes/kotlin/main sounds maybe wrongcommons build.gradle has the following block that was suggested due too a dependency loop i did not understand. just in case its releveant.
// disable all KAPT tasks (kaptKotlin etc.) as only KSP is used
This message has been formatted automatically. You can disable this using
/preferences.Do you have a project named
fabric?
Is that the common project?its a sub project of the client
fabric extends common in the client
https://cdn.discordapp.com/attachments/1380852891828617379/1380852893040509001/fabric.build.gradle?ex=684562f8&is=68441178&hm=a0cbba2f94fd9c963c8166149d477282b8c152e5198f99dc46c3ba688c148a3e&
What do you mean with extending it?
Can you add a
shared-annotation-processor implementation dependency to fabric?
or actually
in common, try changing the shared-annotation-processor dependency from implementation to apithat seems to have fixed those errors or sth. theres a soruce error now but that one is technically to expect due too changing code and it hasnt been updated yet
let me explain why
what does api change vs implementatzion?
Let's say you have projects A, B and C where A depends on B depends on C
If the dependency from B to C is an
implementation dependency, A cannot access classes from C (at compile-time)
If the dependency from B to C is an api dependency, A can access classes from C (both at compile-time and at runtime)
except you explicitly add a dependency from A to C
in your case, A is fabric, B is common and C is shared-annotation-processor
api dependency means "this dependency is made available to dependents at compile-time"i changed most common implementations to api just now
but I have no idea why it tried to compile code from common inside fabric
maybe cus it matters to me that its 1 jar or sth?
idk what you are doing in your build ngl
welp you arent the only one.
ty.
game launched (locking using discord instead of bot)
idk why but for some reason the MinionRepoManager and all other non generated classes are not included in the common or fabric project. I only noticed a couple days after after using those classes.
I have been trying to figure out why in the last couple days but to no avail.
everything reported here is based on a build after clean.
What error are you getting?
just a class not found exception when running. no error when compiling it.
the screenshots i send show all classes in shared annotation processor while they are missing in common. the generated classes are included for some reason i dont understand
Can you show the stack trace?
ugh, bytecode manipulation
maybe try to change the
api to modImplementation?then it causes issue cus local repo
or rather sub project not a repo
@ayylmao123xdd If you ping me, I can also ping you :GnuTrolling:
Do you have Minecraft modding experience?
i have absolutely zero experience on it
but lets see what the problem is
so far you didnt do anything. not even yeterday here or smh
yes
cuz i just walked in here
as it clearly shows on the gif
ez
When nothing is going right, go left!
(Hypixel reference)
Do you have any shadowing/fat JAR configuration in your build script?
Specifically in the one for your final mod
How is that packaged/provided to Minecraft?
fat jar is needed i think
Can you show the configuration of that?
i think its based on
https://cdn.discordapp.com/attachments/1380852891828617379/1382357232557101138/multiloader-loader.gradle?ex=684adbff&is=68498a7f&hm=ca5414a3e68214a05ddaaab3fe7a1925e4c12c5fce0219f721669218fa12377f&
and
https://cdn.discordapp.com/attachments/1380852891828617379/1382357232871538748/multiloader-common.gradle?ex=684adbff&is=68498a7f&hm=c91e17199ebf47309291a1c55ff125d11a537021cf95b9ea3609c42ecec98d82&
How many build scripts do you have?
wdym
How many Gradle files do you have?
should be all .build.gradle files in client code
In your multiloader-common.gradle, there is a
jar{} block.
In that block, try adding the following:
This should hopefully include the shared-annotation-processor in your JAR
...hopefully...
I usually don't use Gradle lol
didnt help it seems
and im aware i have to reload gradle once for it
so whats the current problem
this
can you add a
println(it) in the collect {} block?
and show the output here?
I'm kinda going through some legal/copyright stuff that I have to check so I am not necessarily responding instantly :) (though I might not respond instantly in general lol)dw. I am kinda cheating too rn. im playing games cus i am out of ideas and dont want to experiment and have other things be the problem etc. always replying between ro8unds or if its chill.
download time...
ok so this includes
/home/spieler/IdeaProjects/BingoNet/shared-annotation-processor/build/libs/shared-annotation-processor-1.0-SNAPSHOT.jar
This JAR has the relevant classes, right?Yes
but it's weird that this happens before compiling shared-annotation-processor
well it happens in fabric:jar afterwards so ig it's fine
actually I don't find it there
ps
common did not incluzde it in their jar
it seems
Why do you have split packages?
Are there multiple JARs in the build/ folder of common?
javadoc and source too. nothing else
Can you add shared-annotation-processor as a dependency of fabric?
as an
implementation dependency or whatevercommon is for client code.
shared-annotation-processor is used for server and client code
fabric is for fabric (has fabric mc code)
there technically also is forge (1.8.9 fabric is 1.21.4) but i removed it essentially from intelij a while back but it still means more capabilities in case of future porting.
but that doesn't mean you need split packages (i.e. using the same packages in multiple modules)
wdym
common and shared-annotation-processor both have classes in the package
de.hype.bingonet.shared.compilation.sbenums.minions, right?uhhhhhh didnt ntoice that at least yet let me look
well you have a class in that package there
and the missing class is in that package as well
in principle, split packages are possible but it's not recommended to use them for many reasons and they just cause a lot of issues
uh are you sure. maybe im blind but i didnt see it
only shared-annotation-processor has shared.compilation here no?
What about this image?
This is part of
common, right?
not shared-annotation-processornope. that comes from shared-annotation-prcessor pretty sure. it has a class with that name but for me this does raise a flag. its not generated and included
is it like hmm im not seeing any needed files from here in common. lets leave them out to compact it. and fabric using it is not noticed in common and since it expans common or sth its lost
It might be generated by shared-annotation-processor but it's generated in the compilation of
common, right?no it isnt generated
thats something used in the generation but not generated itself
WAIT
nvm
its MinionTypeS
then where is
shared.compilation.sbenums.MinionTypes coming from?
yesnot MinionType → so its the generated one
but it isnt no?
you have some things that are part of common (even though generated by shared-annotation-processor but that doesn't matter) and some things that are part of shared-annotation-processor in the same package
this is having split packages and this is not recommended
Where you added the
You could try
or similar instead
Execution failed for task ':fabric:jar'.
Entry META-INF/services/com.google.devtools.ksp.processing.SymbolProcessorProvider is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/8.12/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.sounds like its doing something
Is that with or without the
return it?with
What if you remove that one?
or actually maybe
-# will run your filter in a sec
commented the return it it out.
still same error it seems.
well at least that's an error that should be fixable
if it also fails with
filter, you can set the duplication strategy to EXCLUDE I guessjust so were on the same page. it is added in multiloader-common
saw your excldue thingie but idk how,
Execution failed for task ':fabric:jar'.
Entry META-INF/services/com.google.devtools.ksp.processing.SymbolProcessorProvider is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/8.12/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.* 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.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. BUILD FAILED in 39s 47 actionable tasks: 40 executed, 7 up-to-date
like this?
idk where it should be added tbh
I think
duplicatesStrategy = DuplicatesStrategy.EXCLUDE might work as well
or maybe even duplicatesStrategy(DuplicatesStrategy.EXCLUDE)its included in fabric now but not in common
?
like its includeded in the fabric jar but not in the common jar
it might be unproblematic since im not shipping common itself (and only fabric exists too) and inttelij isnt complaining but i dont know whether it could cause issues anyway
also:
(loaded mod list here)
- modmenu 13.0.3
SLF4J(W): Class path contains multiple SLF4J providers.
SLF4J(W): Found provider [org.apache.logging.slf4j.SLF4JServiceProvider@768b970c]
SLF4J(W): Found provider [ch.qos.logback.classic.spi.LogbackServiceProvider@5a4041cc]
SLF4J(W): See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J(I): Actual provider is of type [org.apache.logging.slf4j.SLF4JServiceProvider@768b970c]
...
[18:28:10] [main/INFO] (DevAuth) Successfully logged in as Hype_the_Time
SLF4J(W): Class path contains multiple SLF4J providers.
SLF4J(W): Found provider [org.apache.logging.slf4j.SLF4JServiceProvider@4cde1676]
SLF4J(W): Found provider [ch.qos.logback.classic.spi.LogbackServiceProvider@5fa348f8]
SLF4J(W): See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J(I): Actual provider is of type [org.apache.logging.slf4j.SLF4JServiceProvider@4cde1676]
oh?
I guess that means it works?
read the other messages
so idk
Do you have logback or Apache logging on your classpath/in your dependencies?
i dont rember this error when i launched the game rpeviously so its probably new.
dont think so but jda uses it. i rember errors being printed from them essentially
for me its just a flag that i saw it twice happening or sth. cus like maybe other shit is causing problems due too that too or sth?
well it means you have multiple loggers configured and it doesn't know which one to use