Improving Gradle Build

So this is my current assets.jar building method, it should be identical to Paul’s Example file, but I’ll post it anyway:

project(":assets") {
    apply plugin: "java"

    buildDir = rootProject.file("build/assets")

    sourceSets {
        main {
            resources {
                srcDir '.'
                exclude("**.blend")
            }
        }
    }
}
```

Now while it works as expected, it's re-compiling and re-jarring everything as soon as I change one asset.
I have no real proof for this claim but simply changing a texture of a few kiB takes ~5 minutes to build (`processResources`, `classes` and `jar` Tasks are run).

Is there a genious which could give me a hint about incrementally building them maybe?
I know this netbeans idea (compile-on-save) might lead to trouble but it reduces my workflow-feedback-latency time quite a bit.

There really isn’t any such thing as incrementally updating a jar/zip file. At best, the whole thing is rewritten with the new file inserted in the new version. It’s the nature of the format.

You must have a LOT of assets for it to take a significant amount of time, though.

Is the a very good reason to put the asses in a jar in the first place?
I actually can see only the downside that delta updates are not anymore possible…
Unless you are targeting android od course

well techniqually, the wurm online client does delta updating within the jar files, by just iterating over the single files, but yes I agree, I personally do not use a jar file for my assets as well, simple because it would be several gb big, and a pain to dl, with single files the largest is 10mb, so just redownloading any partial files is way more acceptable.

Currently 1.5 GiB, though I have to take a closer look and clean that up a bit :smiley: It should be less than 100MiB :see_no_evil:

Well, maybe that that’s what JME does by default. But you are right, I don’t know.
Some games handle it like this (multiple containers) to not pollute the file system and it also prevents the files from getting indexed and such unneccessary things.

Actually on my ultimate master plan, I had something like bsdiff so operating on a byte-level, so when you just remove a face, you don’t have to re-download $ASSET_SIZE.
That might be a little over the top though :smiley:

But yeah, I have the impression it re-processes everything since netbeans was able to launch it right away and it only took sokme time when clean&building (Possibly netbeans launched it with the assets being stored in the build folder, so I should re-organize the jar task to some “deploy” master task?