can we have a "forgegradle in a nutshell"

[hydroflame]

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

 

thanks

[AbrarSyed]

#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]

"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]

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]

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]

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

 

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

[diesieben07]

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

Gradle is a build system, like ant. ForgeGradle is the System that has been developed to make forge work with gradle. It replaces the python scripts from MCP. It has a many advantages, such as:

1) Faster setup because gradle caches the downloads like assets and stuff

2) Cleaner setup, no cluttering your workspace with all the forge stuff, all you need is essentially the build.gradle file and you're good to go.

3) Resulting from #2 and from the fact that gradle has dependency management Updating forge is just changing the version number in your build file and re-run the workspace-gen tasks (vs: completely start from scratch with the old setup)

4) and so on and so forth.

[miner101]

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]

... 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]

"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]

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]

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]

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'