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

Treat unexpanded Gradle version property as satisfied dependency #457

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jackassmc
Copy link

This helps when testing mod compatibility with mods that have a dependency on the mod that is being developed.

@modmuss50
Copy link
Member

Another solution would be to set the gradle version from the mod json.

@jackassmc
Copy link
Author

Do you mean loading the version from gradle.properties in ModMetadataParser?

@liach
Copy link
Contributor

liach commented Jun 24, 2021

The main problem is that people can use any custom token for substitution; nothing prevents them from using ${myKey} if they do replacement of myKey in processResources. Hence I prefer modmuss' suggestion, which will make some change to the example mod instead, so its gradle buildscript pulls the version from fabric.mod.json.

@liach liach added the question label Jun 24, 2021
@dexman545
Copy link

Gradle has a json parser - you can simply read the file and set the version.
Alternatively, you can run processResources before launch. Personally, I use the latter.

@dexman545
Copy link

This was also previously discussed in #359

@liach
Copy link
Contributor

liach commented Jun 24, 2021

The best solution would be to make the generated minecraft run configuration run the gradle processResources task and use that resources indeed, which is the behavior of gradle runClient

@jackassmc
Copy link
Author

Gradle has a json parser - you can simply read the file and set the version.

Ah that sounds even better. I'll make a PR for the example mod.

liach added a commit to liachmodded/fabric-example-mod that referenced this pull request Jun 24, 2021
@liach
Copy link
Contributor

liach commented Jun 24, 2021

Fyi I sent a pr, and that works good per my testing

@sfPlayer1
Copy link
Contributor

I think I want to do do two things here:

  1. change example mod to read the version from the json
  2. add a system property to loader to override the version based on mod id (needs to support more than 1 mod id+version pair ofc)

This way the default just works and the classic approach is fixable as well. I don't like the special casing used in this PR, implementing the option 2 from above should wait until my next big PR is in.

@sfPlayer1
Copy link
Contributor

We now have various simple approaches:

  • use the actual version in fabric-mod.json, pull it into the build via version = loom.modVersion (handles all parsing, requires loom 0.10)
  • overwrite the version loader uses with the system property: -Dfabric.debug.replaceVersion=modA:versionA,modB:versionB,...
  • run through gradle as before

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants