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

Slurp mod version from json to avoid issues in IDE #113

Closed
wants to merge 1 commit into from

Conversation

liach
Copy link

@liach liach commented Jun 24, 2021

See FabricMC/fabric-loader#457

Signed-off-by: liach <liach@users.noreply.github.com>
@dexman545
Copy link

I don't think this is suitable for the example mod - other mod properties are set in gradle.properties, it shouldn't be inverted for this one special thing. If auto-run of processResources is really so generally needed, then adding things like Idea's extension so that processResources being autorun will already be configured, or a possible loom change to make it so.

@jackassmc
Copy link
Contributor

Some properties are set in gradle.properties others are set in fabric.mod.json. When using the example mod you'll end up editing both of these files eventually.

@liach
Copy link
Author

liach commented Jun 24, 2021

For @dexman545, I don't think it's quite easy to set the run configurations' resource classpath to the output of processresources. If we can add a correct dependency on process resources for loom, it's good too, but doing it correctly is a bit hard.

@dexman545
Copy link

I'm not sure about what loom can do, but it is worth mentioning as a possibility.

Yes, you modify both files - that does not change the fact that gradle.properties is the correct place for mod version to be set. Few people need this functionality that while it would be good to have, it should be a background thing in loom, not a reworking of the example mod.

@sfPlayer1
Copy link
Contributor

I don't buy into this gradle.properties argument, it obviously breaks in-dev use and alters the product in ways that are too extensive for a build system - a version is no build ID. Neither does it make a different to edit one file or another, having to change both is rare.

Running gradle in the IDE is not a solution, it turns instant run (esp. Eclipse) into waiting for gradle to start+finish and complicates the project setup.

@jackassmc
Copy link
Contributor

Is this blocked until the loader version override is available or can this be merged already?

@modmuss50
Copy link
Member

I added a thing to loom to do this nicely: FabricMC/fabric-loom@2c464cd Will need to wait for a stable build of 0.10

@halotroop2288
Copy link

I added a thing to loom to do this nicely
Will need to wait for a stable build of 0.10

What about 0.7?

@modmuss50
Copy link
Member

What about 0.7?

What do you mean? 0.10 is the version that is being developed atm and will be made stable once its ready. 0.7 was completed long ago.

@halotroop2288
Copy link

halotroop2288 commented Sep 11, 2021

0.7 was completed long ago.

So this feature is already in 0.7 for those of us who still use Java 8 versions?

If it's not, this should be changed:
image

@modmuss50
Copy link
Member

I should update the site, 0.9 is recommended for everyone, you can still use it build mods for java 8 (see fabric API's 1.16 branch)

@liach
Copy link
Author

liach commented Nov 29, 2021

This is already fixed by loom, right?

@liach liach closed this Nov 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants