This message was deleted.
# community-support
s
This message was deleted.
v
Can you rephrase that, or show by example what you mean?
👍 1
d
So, when I run the build task, my project creates a jar file in a directory ending in build/lib. When I run this build task, I would like for it to continue building in that directory but ALSO in another directory of my choosing.
v
May I ask what the actual use-case is for that? This might influence the recommendation.
d
its for faster testing. I build this file everytime I change something in my code, and if I have to copy and paste this file to the other 2 directories every single time it gets a bit tedious.
v
Well, you can easily make a task that copies the output of the
jar
task to those two other directories using
copy { ... }
closure and defining your input and outputs properly, but well, I still don't know why you need that. Sounds like a bad practice, but hard to judge with that little information. 🙂
d
I am testing a minecraft server that requires this jar file in 2 specific directories.
v
Something like
Copy code
val copyJars by tasks.registering {
    inputs.file(tasks.jar)
    val outputOne = layout.buildDirectory.file("testing/a/foo.jar")
    outputs.file(outputOne).withPropertyName("outputOne")
    val outputTwo = layout.buildDirectory.file("testing/b/bar.jar")
    outputs.file(outputTwo).withPropertyName("outputTwo")
    doLast {
        copy {
            from(tasks.jar)
            into(outputOne.get().asFile.parentFile)
            rename { outputOne.get().asFile.name }
        }
        copy {
            from(tasks.jar)
            into(outputTwo.get().asFile.parentFile)
            rename { outputTwo.get().asFile.name }
        }
    }
}
or similar Disclaimer: untested
👀 1
s
bit tangential, but out of curiosity did they ever move away from needing to physically replace the class files inside the jar for "extensions"?
That was always a curious (and silly) approach imo
v
I thought they introduced some "proper" way that does not require a fat jar, but I recently didn't find information about it, so it might still need a bloody fat jar.
s
perhaps, its been close to 10 years since i hacked on minecraft with my son
hence why i asked
and it was never a fat-jar per-se. you literally changed their source files and repacked
d
I am altering and adding files to the minecraft source code if that's what you're asking.
s
ok, so they do still do it similarly. was wondering if MS "fixed" that
i'll step away now, was just curious
so is this second jar the repacked one?
v
Ah, that, there are frameworks doing that for you Spigot and Bukkit or something like that. But you still need a fat jar if you have dependencies you use in your plugin code. That's what i meant.
d
The build function produces 2 jars, the repacked one and one labelled as "mod-name-sources". I haven't touched the second one as I am unsure what it does.
I am fairly new to minecraft modding (started less than a week ago)
s
ah, right.. "mod" that was the name.. not extension
is the "soures" just the java (text) files?
d
I am not sure where to test the example code Vampire sent. I am new to gradle as well sorry 😅
the sources I believe is the java files remapped by the fabric mod community? Not entirely sure.
s
that was my thought.. to distribute your mod source
not sure though - just what seems reasonable
but that would not be 2 jars in the sense you ask about
v
The code I sent is for the build script, but only if you use Kotlin DSL. I wouldn't recommend anyone to use the Groovy DSL.
s
lol
unless you have a massive legacy build ofc 😉
but green-field, i'd agree
d
Does the build script go in the build.gradle file?
I am very new to gradle...
This is what I see in my gradle tab on my project.
v
unless you have a massive legacy build ofc
Never too late to change. It can even be done gradually, they mix just fine. 😉
Does the build script go in the build.gradle file?
build.gradle
IS the build script. But that is Groovy DSL. If it were Kotlin DSL, it would be
build.gradle.kts
.
With Kotlin DSL, you have type-safe build scripts with amazing IDE support, compared to Groovy DSL, so much better error messages if you do something wrong and much more convenience when writing the build scripts.
d
ok so this project was a template I downloaded to be able to mod. So I am not sure what I can and cannot change.
So can I just change the build.gradle to a build.gradle.kts?
You can change anything, if you do it properly 😄
s
It can even be done gradually, they mix just fine.
Oh really? i thought they do not , that is super tangential here. i'll look at it "offline"
d
Where are these tasks created?
s
Depends which group you assign it to
d
These were here when I downloaded the template, I want to read about the "assemble" task
v
As you didn't assign a group if you copied my example, it is in
other
d
Are you referring to the "other" in my image?
s
"other" is the default. and is exactly the one he is talking about
that "level" is the task groups
"build", "help", etc
task.setGroup( "minecraft" ) e.g. changes that
when you write plugins, you often want to group your tasks together
d
Ah I see okay. What about if I want to read about a pre-existing task that I did not create?
s
"read about"?
d
sorry, read the code?
s
iiuc you'd look at the plugin page
many of which are provided by gradle itself
v
Or as you aske for "read the code": https://github.com/gradle/gradle/
s
for Gradle provided ones. yes
if you go to the plugin portal, you can find the source repo for them
v
Which is probably all except for the ones in the
fabric
group. For that, probably the
fabric
source respository.
s
well, generally. some plufins are not good ab ]out that
wow, my typing fu is utterly fubar today
d
Where is this plugin portal?
v
But as Steve indicated, try researching yourself before asking every tiny question. 😉
s
i refrained from using LMGTFY 😉
v
Better so, it was a great thing, but is extremely ugly and ad-pestered now, unless it changed again since I looked last.
s
ah, maybe. have not used that in years also
fwiw @Danielle Paris I get it. the Gradle documention is huge with content often duplicated. And I have sometimes run across places where one duplicated place disagrees with another. Personally I tend to always start with the DSL guide