can we have a "forgegradle in a nutshell"

hydroflame · November 21, 2013

what does it do, how can it help us, etc

thanks

AbrarSyed · November 21, 2013

#1) download and extract the src zip

#2) open command line in that folder

#3) run "gradlew.bat eclipse"

#4) Open eclipse, and point it to the eclipse folder as the workspace

#5) profit.

GotoLink · November 21, 2013

"Better" building process than Maven and "better" dependency management than Ant, supposedly ?

You can migrate from both to Gradle.

That's all i know.

Mazetar · November 22, 2013

I followed the above steps, Worked perfectly

Although it gave me a workspace with an Minecraft project containing just the example mod's src code.

I can see that the example mod is referencing the Minecraft block class without throwing errors, but I can't view the source for it.

So how do I get the files needed to attach the source?

Nvm, it's comming later

Just read Lex's new release post.

At the time of this writing, there are still some features that we are wanting to roll out, namely setupDecompWorkspace which will give you a read-only version of the Minecraft code.

Chibill · November 28, 2013

Can't point it at eclipse folder need to point it a whole forge folder as workspace and only need to run gradlew eclipse it runs the other one because its a dependency.

Lolcroc · January 1, 2014

EDIT: NVM. I was too hasty. Found another topic explaining it

So what is forge gradle in a nutshell? What does it do?

miner101 · January 15, 2014

These steps didn't work for me. The 'src' download didn't contain 'gradlew'. I had to:

Step 2.5: gradle init

Step 2.6: gradle wrapper

*then* gradlew was available.

gradlew seems to correctly download everything. I'm thankful for this because the python scripts have been failing for the past 3 days.

LexManos · January 15, 2014

... The src download DOES include gradlew what are you talking about?

If it doesn't you're not using the gradle version of the src. {Meaning, you're not using 1.7.2 or using 953-}

paul · January 18, 2014

"Better" building process than Maven and "better" dependency management than Ant, supposedly ?

It's not "supposedly" - Gradle is better than both Maven and Ant for many reasons.

First, Maven: Maven is happiest if you do things Maven's way. Customizing your pom is a chore and a half, and despite Maven's dependency management you'll still run into problems with conflicting plugins in a moderately complex project. There's nothing wrong with Maven's build process - it works great out of the box...if you want to play strictly by Maven's rules.

Ant's strength is ease of customization (relative to Maven). While it's true you get nothing free with Ant (i.e. an out of the box build process) the joke is that there's only ever been one build.xml ever written and it's been passed around and modified ever since. Practically speaking anyone developing with Ant will grab an existing build script and quickly tweak it for new development work. Ant does not come with any dependency management - that has to be added on via Ivy. Ivy itself is a pain to configure so it's not like Ant+Ivy is a dream solution.

A major problem with both Ant and Ivy is their respective build scripts (build.xml and pom.xml) are both written in XML. XML is not a scripting language - it's a markup language. Any solution based on scripting with XML is going to be problematic. This is not a knock on Ant (which I love) and Maven (which I don't) - when both projects were started XML was arguably the best choice for the next generation makefile.

Enter Gradle (of which I'm a huge fan)...Gradle combines the best of Ant and Maven while improving on both. Gradle's "makefile", build.gradle, is written in a domain-specific language based on Groovy. Groovy itself is pretty, uh, groovy, but that's a lecture for another day Gradle comes with out of the box capabilities and dependency management a la Maven and is even more flexible than Ant. Gradle uses Ivy under the hood and the integration is done so well that dependency management is easier to configure than it is in Maven.

Whoever had the foresight to go with Gradle should get a raise

That being said, the Forge build process is kind of a mess (the absurd number of tasks in build.gradle are evidence of that) and I think that's a big source of confusion for a lot of people. No matter the build tool of choice (Ant, Maven, or Gradle), the use of an IDE should not be a factor if the build is constructed properly. It should be possible to pull down the code out of [Git, SVN, whatever] and build a working distro straight from the command line (yes, even with all the hoops that must be jumped through for Minecraft modding). When it's possible to build a freshly exported codebase from the command line then it's trivial for a developer to use any IDE or text editor. The more time spent mucking with the build means less time doing the fun stuff...writing code!

Oh, and hi, I'm Paul. I'm pretty handy with Java and such but completely new to Minecraft modding and Forge so I'm sure I'll have a lot of questions. I'm happy to answer what questions I can and hope to be able to contribute to the project at some point.

Paul

LexManos · January 18, 2014

That being said, the Forge build process is kind of a mess (the absurd number of tasks in build.gradle are evidence of that) and I think that's a big source of confusion for a lot of people. No matter the build tool of choice (Ant, Maven, or Gradle), the use of an IDE should not be a factor if the build is constructed properly. It should be possible to pull down the code out of [Git, SVN, whatever] and build a working distro straight from the command line (yes, even with all the hoops that must be jumped through for Minecraft modding). When it's possible to build a freshly exported codebase from the command line then it's trivial for a developer to use any IDE or text editor.

Its not a mess, more tasks != mess. Would you rather us bundle everything into a single task and make you have to rerun EVERYTHING every time you setup your env?

As it sits, all you have to care about are the setup* tasks.

paul · January 20, 2014

Its not a mess, more tasks != mess. Would you rather us bundle everything into a single task and make you have to rerun EVERYTHING every time you setup your env?

As it sits, all you have to care about are the setup* tasks.

Don't get me wrong, from what I've seen elsewhere I think Minecraft Forge has the best API and build process going. If having a boatload of tasks works for the developers and modders, great.

My opinion is that the number of tasks could be greatly reduced by eliminating IDE-specific tasks through an IDE-agnostic build process. It's also possible the codebase may lend itself to being organized into subprojects but I haven't had a chance to play the with code yet. I just today finished another side project (building and securing a Multicraft server) so with any luck I'll finally get to tinker with some code!

Paul

LexManos · January 20, 2014

It is a IDE agnostic process, with IDE specific addons because modders are to stubborn/stupid to setup there run configs themselves.

There are only two tasks you should care about 'setupDevWorkspace' and 'jar'

Sign In

can we have a "forgegradle in a nutshell"

Recommended Posts

hydroflame

AbrarSyed

GotoLink

Mazetar

Chibill

Lolcroc

miner101

LexManos

paul

LexManos

paul

LexManos

Join the conversation

Announcements

Recently Browsing

Posts

Topics

Who's Online (See full list)

Browse

Activity

Important Information