Update signing process to root certificate

[msteiger]

This commit removed the self-signed applet and uses one from the Certum CA. It also fixes a few issues with the gradle build.

[msteiger]

The lwjgl_util_applet in the distributions folder has an invalid Application-Library-Allowable-Codebase attribute. It should be * but is true. Can we do something about that?

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#app_library

[Cervator]

Since we're resigning everything again anyway I figure sure, during the build we just add a step to tweak and reassemble that jar. If I'm correctly interpreting your meaning, anyway.

Alternatively maybe nobody raised that as an issue with LWJGL after the applet security changes? Maybe it could be fixed in a newer version.

[msteiger]

Ok, it basically works now. Open issues:

• The engine and Core jar are not yet included in the jar list in index.html
• Adding them as deps. causes all transitive deps. to be added too (they are already in the libs folder - maybe we can remove that?)
• Is the applet supposed to be a subproject or is it a standalone "wrapper" project?
• Would it make sense to upgrade to Java Webstart? I heard that this is what the cool kids use..

[immortius]

Core doesn't need to be in the jar list - as a module it is downloaded by the applet itself.

On 29 March 2014 07:22, Martin Steiger notifications@github.com wrote:

Ok, it basically works now. Open issues:

• The engine and Core jar are not yet included in the jar list in index.html
• Adding them as deps. causes all transitive deps. to be added too (they are already in the libs folder - maybe we can remove that?)
• Is the applet supposed to be a subproject or is it a standalone "wrapper" project?
• Would it make sense to upgrade to Java Webstart? I heard that this is what the cool kids use..

Reply to this email directly or view it on GitHubhttps://github.com/MovingBlocks/FacadeApplet/pull/1#issuecomment-38963961 .

[msteiger]

If I'm not mis-understood, @Cervator and I agreed to include all relevant jars through the gradle dependency management system. This is why I dropped the support for the downloading in the applet startup phase.

I think that it would be nice, if modules could be downloaded in-game on demand in both the applet and the normal game (tbd later).

[immortius]

I'm sorry but modules don't go on the classpath, or in the lib folder. They belong in the modules folder. That is where the engine expects them and where it looks for them.

Modules are already downloaded as needed from servers.

[Cervator]

I'm sorry about the confusion :)

I meant we can fetch the needed modules via Gradle in the first place (including the engine jar now with the latest round of Gradle changes), at build time, but then we need to make them available for the applet at runtime via the distribution - whether that's by loading them locally (within the applet package) or remotely (the existing applet module download step) isn't a big distinction to me (there may be benefits to remote download - security/file system stuff?)

In how it used to work the build process would create all the modules (from before the Great Convergence - so they'd all be created during the single uber build that did everything) and package them up together in Jenkins. Then the applet deploy would put both applet and modules in the same spot on the website - but it was more or less just coincidental that they were in the same place since the applet would end up loading them via the web anyway. They just happened to all live together happily in Jenkins. Now all that is split up.

I was thinking loading them from within the applet package itself would be nice, especially for local testing, but Immortius mentioned having been able to do that in the past - maybe I just haven't spotted the right path to tweak for local testing

Either way we do need to actually fetch them via Gradle/Artifactory, as they wouldn't be produced by the same build that makes the applet anymore. At least until there is some sort of in-game facility to auto-download from within the game (and a standard line-up to offer for download). Only current alternative would be to download them straight as attachments from Jenkins/Artifactory at runtime

If it seems wrong to add the modules to a Gradle config to force the download ("compile" config) then yeah I can understand that - although really we'd probably just use a differently named config to do the same thing (probably simply "runtime" config, or the "applet" one in this PR). The list of modules to bundle could be added via supplied properties in Jenkins, just like it works in the PC build for zip distribution now:

https://github.com/MovingBlocks/Terasology/blob/develop/facades/PC/build.gradle#L153

Does that all make more sense? The key is that we need to fetch the modules differently at build-time now than we had to before the Great Convergence. Even if we use them the same way at runtime.

Edit: Just for the sake of mentioning it, we could even do a completely separate build job in Jenkins that would copy a set of modules to a spot on the website where the applet can download them. So applet builds in one spot without modules, gets deployed to the site, modules get deployed separately. But we'd still need the script that does the modules in some repo, and the applet one makes the most sense IMHO, using Gradle to declare which modules we want :-)

(We still could alternatively make a module copy job like that grab modules entirely without Gradle, but then we'd be copying them as hard links out of Jenkins or Artifactory, which seems potentially fragile to me)

[msteiger]

We could use the Artifactory Java Client to download modules from Artifactory in the Applet bootstrapping phase (and maybe later in a in-game module browser):

https://github.com/JFrogDev/artifactory-client-java

EDIT: I just tried it out. It's not fantastic, but it gets the job done. We could package engine with the applet and download modules on-demand from within the applet.

[Cervator]

That one does seem a bit thin on documentation, unless there's a nice wiki page for it somewhere :-)

Long-term I don't think we should aim to use Artifactory (or Jenkins) for any runtime or in-game download options, lest we risk melting our web host some day. Build-time is fine since that's just once per build.

When we can publish actual released jars to their respective GitHub repo release pages I think we'll be in better shape. Even an official module tracking site would need a One True Source spot to download from. Only devs really need the full Artifactory integration.

In the meantime I think the only real requirement we need to meet right now is where to get modules to prepare at build time, now that they aren't in the same repo as engine/applet. They can download the same way they did before until we have a more suitable module distribution setup.

I'll try to play with the last bit of Gradle for this today and tomorrow after finalizing the new transitive dependency fun

[Cervator]

Merged and forked to Nanoware for further Gradle integration, Jenkins, and all that jazz. Going to work on it together with updates to the PC distribution itself, first in a local mega-workspace then will see if it can work in a solo Jenkins build :-)

AWT facade too, actually, since it is in a similar boat as the applet

Thanks!