Best practice for updating to latest 1.7.2 build

[dhuntley1023]

Is there a gradle task or command-line parameter that will force it to download and compile the latest build in an already existing environment?  I've been through all of those that look like they'd do that and I don't see the download steps being performed.

 

If not, what's the best practice for updates?  I saw "easy upgrades/downgrades" as one of the benefits of the new system, but it's not clear to me yet how to accomplish that w/o downloading and recompiling the whole release into a new directory each time.

 

Thanks,

 

David.

[LexManos]

All the things that are cached/linked in by the gradle are keyed by the forge version you specify in the build.gradle

However, one of the major benifits to gradle is that A LOT of the stuff is cached, which means that A LOT of the stuff you see will not be performed again.

Example that you brought up, the download tasks, the only thing that updating a new Forge version has to download is a small userdev package. Which is done transparently in the background.

Beyond that the first time you setup with a new forge version it'll rebuild the binpatched jar, and the decomped code if you tell it to.

After that, there is no reason for it to rebuild things as it already has them.

 

[dhuntley1023]

Thanks Lex.  That was helpful.

 

For future reference, here's what I found to work to to update your 1.7.2 forge environment to a different release (either forwards or backwards):

 

1) Shut down Eclipse.  I found Eclipse was unhappy w. gradle changing config files out of under it if I left it running during the update.

 

2) Edit the build.gradle file located in the base directory of the forge tree, and update the version to the build you want to use (see example below).

 

        minecraft {

            version = "1.7.2-10.12.0.982"

        }

 

3) Execute the same gradle commands you used to setup your environment the first time:

 

        ./gradlew setupDecompWorkspace

        ./gradlew eclipse

 

4) Startup Eclipse again 

 

You should be able to verify that the environment is using the right version of forge by checking the Build Path on your Eclipse project. Right click your project folder in the Eclipse Package Explorer and select Build Path->Configure Build Path.  In the Libraries tab, verify that the desired version of the forge library is being used.  I.e. Look for the library "forge-1.7.2-...".  It should match what you put in the build.gradle file.

 

 

Separately... here's another way I think this can be done.  Before learning about the above, I was experimenting with a different build arrangement where I downloaded and configured each build into a different build-number named directory.  Then, I created a completely separate Eclipse workspace/directory for my mod (i.e. not within the Forge build).  For each Forge build, I imported (w/o copying) it into my workspace.  The result was that I had a very clean project w. only my mod code, and had each of the Forge builds I had downloaded referenced there.  Now to get it all to build, I updated the build path on my mod project to reference the Forge build project of the desired version.  (See the Projects tab under Build Path->Configure Build Path).  If I wanted to switch to a different Forge version, all I needed to do was to select the new version and deselect the current one.  Also, to do it this way, you use all of the same build/run settings as when your mod source is within the Forge build directory. (Arguments, Main class, etc.)

 

Anyway, that's my 2 cents.  There could be some issues I'm not aware of yet, and I'm also interested to know how others have setup their environments for easy mod and build management.

 

David.