This requires that current build problems get sorted out; after that, the build script will need to be slightly rewritten (we'll need one for local building, and one for Jenkins building). Then, once it's working, we should be able to create a new script on tei-c which can push the new build of oxygen-tei directly to SF and update the Oxygen add-on update file.
Making Green and assigning to Martin Holmes to investigate and implement the scripts.
Per James: We also need to change the update file so that it lists all previous releases, enabling users with older versions of Oxygen to roll back to a previous release of the plugin.
We also need a step for signing the jars, between the build and the release. The Oxygen folks presumably sign the jars as part of their own release process, but ours are not currently signed.
FWIW, I looked at this when we first started, and didn't understand how to sign jars. i believe its not entirely obvious, and that you need certificate-signing authority, i.e. its not just self-certification. I may be wrong tho.
Sebastian: I had a quick conversation with the oXygen guys when in graz for DiXiT about this. They seem to just command-line script.
I have a basic build process working on my Jinks, but I don't know how to set up jar-signing yet. We need a discussion about this.
Jar-signing is on the backburner for the moment, since we're not doing it for released builds anyway. I now have a working Jenkins build script which uses the locally-built latest versions of the Stylesheets and P5 to create the package. It names the package oxygen-tei-2.7.1a-7.30.0.zip (as opposed to the rather confusing teioxygen labelling we currently use for releases, which does not match the Google project name and conflicts with the TEI deb for Oxygen), The Jenkins config and a README.txt about the requirement for a recent oxygen.jar are in SVN as of rev 13119.
What remains:
This is now working as planned.