As I see it, the minimum functionality we need to split freenet-ext.jar is: - A manifest file in freenet-ext.jar listing each, for other file that the new freenet-ext.jar depends on: -- The filename of the latest version of the file. (it will be stored in lib/) -- The stem of the filename, for garbage collection purposes. -- The SHA256 of the latest version of the file. -- A CHK to fetch it from. - The freenet-ext.jar itself would refer to the files in lib/ via the usual Java mechanisms, so we don't need to update wrapper.conf, except to switch from the old freenet-ext.jar to the new one. freenet-ext.jar is a secondary jar and we don't use java -jar, so it's possible we need to update wrapper.conf. If we do, we need to extend the wrapper.conf rewriter to include the new jars, whether or not prior versions exist already; provided the filename stem's don't overlap, this is fairly straightforward. - We do not need radical changes such as calling out to a script to replace everything and restart freenet, because we are simply restarting with different files - we never need to replace anything. - Filenames always change when the file contents change. If they are not being updated, they will be on our classpath - we can ask the wrapper, or read wrapper.conf. - After restarting, we can garbage collect in lib/ - identify libraries that are older versions of what we are using now, and delete them.
So a relatively small set of changes allows us to split up freenet-ext.jar properly: - Create the manifest file in contrib (initially by hand). Update the build scripts to include it in the built jar. - Analyse it when we have a new freenet-ext.jar to deploy. - Check the versions of the current libraries by asking the wrapper for a list of jars loaded, or reading wrapper.conf. - Any that are not loaded must be verified on disk. If they're not on disk they must be downloaded. Once we have all of them we are ready to deploy. - Do we need to update wrapper.conf? If so, changes must be made to support patching in the new versions of jars (and the new jars). - Garbage collection is an optional extra. There are several further complications: 0. Installers We can easily include more files. This is not a big deal. 1. update.cmd and update.sh These will need rewriting so that they can download all the new files, when run from old versions. This is easy-ish on unix but somewhat less easy on Windows. 2. Updating the wrapper itself We have to update the wrapper jar at the same time as the wrapper binary, and can't do the latter while the node is running. So we will need to download the new wrapper files, then start a script, which waits for the node to shut down and then substitutes all of the new wrapper files, and then starts the node back up. IMHO this does not involve a fundamental reworking of the updater, and in fact, it can be implemented in stages if it's useful to do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120406/21cbcb8a/attachment.pgp>
