updates.jmonkeyengine.org is down.

[Fluturenet]

the update site is down. It's two days that I receive this error. I'm using the Linux 64bit stable version.

[Ali-RS]

Yes it has been down for a long time. Just uncheck them from Tools ->Plugins -> Settings menu so netbeans don't check them.

[g-amador]

Any prediction if or when they will be back?

Also the NBAndroid url is also wrong its

http://nbandroid.org/release81/updates/updates.xml

as explained in

https://bitbucket.org/nbandroid/nbandroid/wiki/Installation

[MeFisto94]

I already tried to message some cloud provider but their response after 5 days was simply that I should open a stackexchange question and tag them...

The problem is that we do not want to setup a self-hosted update page any more, because as it happened, when they key members who organized the hosting, have the passwords, w/e, are unavailable, the site goes down again.

That is why we are looking for a simple file storage possibly with easy deploying through webdav or something and some OAUTH possibly with github.

So we are currently looking for all that and an open source plan for free, however Google Drive, Dropbox and other suggestions don't really provide an easy file tree access (meaning that the file structure is exposed in the URI)

Edit: I have now updated the NBAndroid Path. If someone has knowledge about other android related bugs, feel free to report them as well, I've only noticed that it seems cumbersome and some guys even use Android Studio.

[tlf30]

An update repo with GitHub is not too hard for NetBeans platforms. First, make a GitHub repo for the update repo. You will put all the update files in here: updates.xml, *.nbm, etc...

Second, in the updates.xml all files names need to have ?raw=true added i.e: <module codenamebase="test.nb.plugin" distribution="test.nbm?raw=true" ... and <license name="AD9FBBC5" url="licenses/AD9FBBC5.license?raw=true"/>

Third, the update URL in NetBeans, in this case jMonkey, will be: https://github.com/jMonkeyEngine/<repoName>/blob/<branch>/updates.xml?raw=true

I have used this method before and it worked fine for me, on the other hand I was working on a much smaller platform. Hope this helps. ~Trevor

[MeFisto94]

This indeed helps, I am only thinking about how good git is for such things since we have the 100MiB Filesize limit and since the repository size grows dramatically when you can't diff files like binaries.

In addition to that we don't need previous revisions, so it might be a good idea to reset the master branch each new release? I don't know the consequences if you have checked out the repo, but no one should do that anyway.

And we might need a user so travis can push to git, not sure if there is something like an OAUTH key we also use for releases? mh

[tlf30]

I do not see any reason why we could not just keep updating the master, and I think if a commit was done with the new files added the the old ones removed, even cloning the repo should not be a problem. The user and OAUTH key I am not sure about.

I have a test repo setup for one of my applications right now, it is working really well, if there is something you would like me to test on it just let me know.

~Trevor

[tlf30]

Found out how to make it even easier. If using https://raw.githubusercontent.com/<user>/<repo>/<branch>/updates.xml Then you do NOT need to modify the updates.xml to put ?raw=true on the end.

For example, just uploading the files to a repo names SDKUpdateRepo: https://raw.githubusercontent.com/jMonkeyEngine/SDKUpdateRepo/master/updates.xml should work even better.

Edit: After looking at the layer.xml and Bundle.properties for the update center, I think having three branches: stable, nightly, and contrib would allow us to set up the update repo exactly as it was before. The only change that I can see that would have to be made is changing the three URLs in the Bundle.properties.

[MeFisto94]

That actually sounds really good.

I do not see any reason why we could not just keep updating the master, and I think if a commit was done with the new files added the the old ones removed, even cloning the repo should not be a problem.

Technically the problem is that git always stores the whole history in it's repos, which is also why you can work offline completely. This however leads to a huge increase in size over time, even though it's hidden for the user.

For instance, try a du -sh .git in your current update repo. On the other hand we can work around that issue if we reset the repo every time. So we only need to ensure that our modules are smaller than 100MiB and I might give it a try on a private repo first

[tlf30]

Does anyone want to look into this again? I think it is time to get updates working. Even a temporary solution would be fine at this point.