Jump to content

Minecraft Works in Eclipse but build.gradle Fails


MrrGingerNinja

Recommended Posts

Hi, forum dwellers!

 

I recently started a post on the Minecraft Forums regarding a dependency issue I was facing with the build.gradle file when trying to build my mod for release.

 

coolAlias on the forums helped me out with fixing this dependency issue, but I am now facing another problem that has left both him and I stumped.

 

I have set my Eclipse workspace up in the "Pahimar style"; i.e. creating a new project for each mod and make the mod's project depend on the Forge project.

 

The dependency issue I was facing was that my current mod also depends on an API project inside of Eclipse; to fix the issue, coolAlias told me to build the API (which works), then put the .jar file into a folder called 'libs' in my mod's project and add the following beneath the

apply plugin: 'forge'

line:

 

dependencies {
compile fileTree (dir: 'libs', include: ['*.jar'])
}

 

This works absolutely fine and I am grateful for that.

 

However, I am now facing an issue where the build.gradle script fails at the ":compile" step due to the following error:

"error: TileEntityChestIron is not abstract and does not override abstract method isItemValidForSlot(int, ItemStack) in IInventory".

 

Now, Eclipse does not tell me this error; it is happy with my structure (which involves a LOT of abstraction, just as a heads up).

 

TileEntityChestIron extends TileEntityChest (my own version). TileEntityChest is an abstract class that extends TileGUI (part of my API). TileGUI is another abstract class that extends TileInventory (another abstract class, part of my API, that implements most of the core IInventory methods, including isItemValidForSlot).

 

I copied the isItemValidForSlot method from the TileInventory class and put it into TileEntityChestIron and, when running the build.gradle file, the script failed again, this time complaining about not overriding abstract method closeInventory().

 

Does anybody know why this is happening and if there is a way to fix this issue? I made the API project so that creating inventories or GUIs or whatever is easier on my watch and makes my code look WAY neater. But this is becoming a real annoyance for me.

 

Thanks in advance; I appreciate any help anyone can give me :)

Link to comment
Share on other sites

First of all: Don't make a separate Forge project. Each Mod project should be a normal Forge Workspace as you set it up with Gradle. No "Forge Only" project. Forge is a library, no need to make a separate project for it.

For your compile errors: Did you let gradle build your library mod without reobfuscating?

 

The setup I have regarding Forge works absolutely fine with any other mod that I have built with the build.gradle script. I have had no run ins with any other problems, so unless this is the cause for the problem, I am going to keep the structure I have?

 

As for the library mod, I ran the build.gradle file for this, as if it was a mod being released. Was this not the way to handle this?

Link to comment
Share on other sites

I am not saying it doesn't work, I am just telling you: It makes no sense whatsoever (and btw. this is not what Pahimar does).

I apologise if I seemed arrogant in that post; it's just that my setup seems to work okay and I didn't really want to have to change my entire workspace layout. Especially as the majority of my workspace is in a Dropbox folder on my PC, synced with a select few who help develop the mods I am working on. It's easier for us all if I kept the workspace as it is :)

 

And I apologise for stating that this is the way Pahimar does it; I saw some tutorial videos where he sets up each mod in a different project, but that's all I knew... I assumed he was doing it the way I do. Sorry again.

 

Yeah, that will not work. If you run gradlew build it will reobfuscate the mod so that it can run in the normal Minecraft environment. You will need a non-obfuscated version of your library mod to build your normal mod. Look here on how to do that: https://github.com/diesieben07/SevenCommons/blob/master/build.gradle#L48

Thank you sooooooo much. I have finally got it working now, placing the 'deof' version in my 'libs' folder and then the actual version in the mods folder when running the mod outside of Eclipse.

 

Thanks for all the help; I really appreciate it! :D

Link to comment
Share on other sites

Jautsch. You should use Git, that is much better for sharing Code. The workspace data should not be shared, only the actual Code. Then everyone can set up their workspace however they want without interfering with each other.

Believe me, I would use Git to do this; I upload the majority of my code to BitBucket using Git as it is, but some of the other code authors don't know the first thing about using Git and this was an easy temporary solution. When I update my Forge version again, I will probably show them how to use Git properly.

He used to do it in the pre-gradle time, because at that time it was needed to keep the Forge-Code and your Mod-Code separate. Now that is not needed anymore, because ForgeGradle lets you use Forge as if it was any other library.

That makes sense; like I said, when I set up a new version of Forge, I may take a look at setting it up in the way the Gradle intended for it to be set up as a library; thanks so much for all the help :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.