Versioning assets

Does anyone version their assets.jar?

1 Like

I version the assets in the jar… but not the jar. I don’t version my .class files either.

Edit: Or do you mean like giving it a version number? I immediately thought “source control”. Sorry… maybe ignore me.

yes.

I cannot think of a way for my updater to know if it needs to update this or not as there is no version.

Versioning asset jars makes total sense to me. If I get Mythruna to the point of release again, I will certainly be looking at not only having asset jar versions… but also more than one asset jar.

It’s trivial to add to the gradle setup, too. So no big deal either way.

Heh, unless its me.

Every single thing I do to date, unrelated to jme that is, requires some sort of above and beyond effort.

I don’t know how you have your assets project setup, so I can’t comment.

If it’s from the template then adding version=whatever inside the project definition should be enough, I think.

I version assets between my server and client by using the date modified timestamp on the server.
The client pulls a list of assets and ‘version numbers’ from the server, and if the version number does not match what the client has in its repo metadata, then it pulls the new asset.

The client keeps the metadata in a text file with the version attached to each asset file name. The server just uses the data modified to create a long timestamp as the version.

Except I use a plugin for semantic versioning and cant use “version” define. Its set by the plugin automatically and requires not having the define in the build file. It seems its not setting it during configuration phase. Probably need to ask the plugin guy whats up.

I am using jpackage to install the app and that becomes a problem as it sets the file timestamp to when its installed.

So the first time the app is ran, it would want to download everything it just installed. I use standard semantic versioning for everything so that eliminates the need to timestamp. Just the assets jar isn’t versioned so thats why I asked about it.

I will be posting another thread soon on versioning for the JRE thats bundled with jpackage as it has no way to update it as near as I can tell.

Got it to work using a callback from the asset project closure.

    project.gradle.projectsEvaluated {
        version = "$semver.version"
    }

Edit: Just remembered that I am syncing assets from an ant project, I need to version the thing before sync. Doing what I did will make it match the current projects version.

That works. I do not use timestamps on the client, only on the server to generate the version numbers. The client saves the asset versions in a text file. It is just an easy way to generate version numbers automatically on a server.

I have never used jpackage, does it work well?

Yes. Its nice as it builds and includes the jre with no effort on your part.

Using gradle with java 14 gives the ability to use github to build mac, win and linux distributions either automatically when pushing to github or by tagging a release.

I am not certain about the jre updating as I havent figured out exactly whats going on there yet. Seems like there should be a way to trigger an upgrade without me doing it through an updater.

I use a CoW approach - if the client has an asset cached locally it’s used, but if the object is modified on the server then any “updated” assets end up as a totally different asset binary that’s fetched on-demand. If you’re bundling assets this doesn’t work well, but in my case the assets are always handled individually.

I use this tool to manage my releases. Easy to use and it takes care of automated upgrades for you. https://github.com/threerings/getdown

Well as I said before

I found out that I was not fully understanding how the build phases of gradle work. I discovered that the copy type runs in the configuration phase, where a execution type runs in the execution phase and as I was using project.sync for other things related, thats the initialization phase.

Anyway, getting the three phases to work correctly, with application plugin, with custom tasks, using commandline (exec phase) was nearly a two week nightmare of figuring out the build phases.

Got that done, was about to implement my new plan to use the server project to always version the assets jar when I noticed that my updater project would not autocomplete, refactor, had broken navigator, and nothing basically works.

So I spent another couple days trying to get that fixed. Only to discover that theres a bug in netbeans 12, at least I think it is a bug, where if you use a simple anonymous class to walk the file tree, this type here,

            Files.walkFileTree(sourceDirPath, new SimpleFileVisitor<Path>(){
            
            });

the new SimpleFileVisitor<Path>() will break netbeans.

Took 3 days to find this. Once again,

2 weeks down, and I mean full days, 7 days a week nearly, and I am still basically right where I started this adventure at.

I cannot for the life of me understand why I find every dam possible bug in the world in every dam dependency, plugin or program but I do.

2 Likes

I hope you report them as well. Doing so you are a hero. Paving the way for us peasants.

Yes. Always. Not sure how fast or if they will even respond.

1 Like

I installed netbeans 12.1 but this time I didn’t import settings.

Previous install was updating from oracle netbeans 1.8 to apache netbeans 12.0

This now works.

We will see if it breaks again.

Edit: I went through all the commits for 12.1 and there was nothing that was obviously fixing my problems so thats why I think something was off with settings. Might of been something else though.

1 Like