Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a tag, modified another #46

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions tags/faq/artifacts.ytag
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
type: text

---

After compiling and exporting your mod to a JAR archive, you will notice that there are four files inside `build/libs`.

*Which one to use?*
TL;DR use the one without `-sources` or `-dev` (the shortest one).

**What do they do?**
Let's walk through the compilation process (when you run the `build` task):
- Firstly, Gradle compiles your mod normally using the `jar` task to produce the `-dev` JAR (Loom changes the `jar` task's classifier to `dev`).
- Secondly, Loom remaps the produced JAR (`-dev`) to the intermediary names (`remapJar` task). These names are used in a production environment (this is the JAR file without a classifier).
- Additionally, Gradle also produces a sources JAR using the `sourcesJar` task (`-sources`). This JAR uses the mappings you configured (the same as your real sources).
- Then, Loom remaps the sources to intermediary (`remapSourcesJar`), changes the original sources JAR name to `-sources-dev`, and produces its own intermediary sources JAR (`-sources`). This uses source code remapping, and as such, won't work with languages other than Java.

**What does all this mean?**
42, obviously.

As mentioned earlier, the intermediary names are the names used in a production environment, and as such the classifier-less JAR is the only one that is usable outside a development environment.
When depending on other mods using Gradle, it is still recommended that you download the JAR without a classifier (and not append `:dev`), because the named JAR may use outdated/different mappings than your project. (Same for sources)

The sources JAR is, of course, unusable and isn't runnable JIT-able code. It should only be used in IDEs.
2 changes: 2 additions & 0 deletions tags/guide/build.ytag
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
type: alias
target: guide/export
5 changes: 4 additions & 1 deletion tags/guide/export.ytag
Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,7 @@ type: text

---

Exporting your mod as a JAR: run in a terminal from the same directory as the mod project directory `./gradlew build` on GNU/Linux and Mac, or `gradlew build` on Windows. Alternatively, in IntelliJ IDEA, open the Gradle tab on the right and execute `build` under `tasks`. The JARs should appear in `${projectDir}/build/libs`. Use the one with the shortest name outside development.
Exporting your mod as a JAR file: Run in a terminal from the same directory as the mod project directory:
`./gradlew build` on GNU/Linux and macOS, or `gradlew.bat build` on Windows (`.\gradlew.bat build` in PowerShell).
Alternatively, in IntelliJ IDEA, open the Gradle tab on the right and execute `build` under tasks. The JARs should appear in `${projectDir}/build/libs`.
Use the one with the shortest name outside development.