I have updated https://hub.docker.com/r/stain/jena-fuseki/ to have Fuseki 2.3.0 on the 'latest' and 2.3.0 tags.
docker pull stain/jena-fuseki should pull 2.3.0 I would prefer to not to have this under /stain/ so it can be made official and managed by more than just me. I'm afraid progress in adapting the docker image was stalled here: https://github.com/apache/jena/pull/50 https://issues.apache.org/jira/browse/JENA-909 I have rebased the pull request for the latest master. We should still think about how the release process would work before such a pull request is accepted. The pull request adds a jena-fuseki2/jena-fuseki-docker module - which only purpose during normal Jena build is for its version number to be updated as part of the release process. Within the Dockerfile it downloads the apache-jena-fuseki.tar.gz distribution from Maven Central (or http://repository.apache.org/snapshots) This makes a convoluted Docker build than strictly necessary, as it uses Maven only to resolve apache-jena-fuseki.tar.gz. It does however fit well into the current source code hierarchy and it means downstream users can just run "docker build ." in that folder to build it for themselves. https://github.com/stain/jena/blob/fuseki2-docker-maven/jena-fuseki2/jena-fuseki-docker/Dockerfile A simple approach (the one Andy mentioned that I tried first) is to just have a Dockerfile that downloads the specific release, e.g. https://github.com/stain/jena/blob/fuseki2-docker/jena-fuseki2/jena-fuseki-docker/Dockerfile This would fit better in a separate git branch/repository or at least outside of the Maven build (as it would have to be updated manually after a release). Now should such a repository be owned by Apache Jena? I think it should. If not, then it should be a separate Dockerfile-only project - like I did for Virtuoso: https://github.com/stain/virtuoso-docker ((.. but this could potentially raise ASF trademark alarms!)) Even with Maven updating this automatically, manual updates of the docker hub on https://hub.docker.com/ would still be required. Normally the Automated Build works well, but it can only be set up from a GitHub repository you have control over -- but Jena committers can't (easily) register automated builds against https://github.com/apache/jena/ (it's a read-only mirror) -- with a bit of push and luck INFRA could possibly do it though. One alternative here could be to push it manually to the Docker hub. This could be added to the Maven build with some Docker-maven plugins -- but this would mean the Jena Release Manager would have to have Docker installed to complete the release. Should the Docker image be covered by the [RELEASE] vote? By putting it into the Maven source build that is voted over anyway, and by the dockerfile just putting the jena-fuseki distribution tar.gz that was pushed to Maven Central by the same vote - and thus by my reasoning pushing this elsewhere is not a new release or new binary, more like a kind of rewrapping (like changing a .zip to .tar.gz) - your views might differ. More appropriate would be to register as an official image (e.g. "jena", "jena-fuseki" or "fuseki") - see https://github.com/docker-library/official-images -- this is a bit more work to do properly and generally puts the Dockerfile content in https://github.com/docker-library/ - see for instance https://github.com/docker-library/httpd and https://github.com/docker-library/tomcat .. I think this would mean keeping (quite minimal) source code outside Apache's control and not quite by ASF policy as for a new release you would need to afterwards need to submit changes to the https://github.com/docker-library/jena library. You can also refer to external repositories like in https://github.com/docker-library/official-images/blob/master/library/nginx - going this route we could just refer to the commits on https://github.com/apache/jena and even use the same commit ID as used in the VOTE. It is this I was thinking of with my maven approach, as it means 'anyone' can raise a pull request against jena in https://github.com/docker-library/official-images/ to just point to commit IDs of later releases - the Jena source code would have already the right Docker bits in it. I had hoped we would go down the route towards the official image I mean official as in gradually moving down: - Dockerfile Source code owned/managed by Apache Jena - Docker Hub entry uploaded/updated by Apache Jena committers / Release Manager - Docker image linked to from Fuseki documentation - Official "_" Docker Hub entry - but if there's lacking interest in the Docker image to be officially part of Jena in any form, I would rather just split it out and keep maintaining it as a personal slightly outdated thing. On 10 September 2015 at 15:50, Andy Seaborne <[email protected]> wrote: > On 10/09/15 13:56, Reto Gmür wrote: >> >> Hi Stian, all, >> >> I've been using your docker image from dockerhub. However it is using >> quite >> an old version of Fuseki and the last commit in the respective branch of >> your fork has been a while ago. >> >> Areyou planning on updating this tothe current fuseki version or is there >> another dockerized version of Fuseki. >> >> Cheers, >> Reto >> > > The Dockerfile has "ENV FUSEKI_VERSION 2.0.0" That, and the java7 root, > should be all that needs changing. > > > FYI: to run containerized from a local Fuseki distribution: > > Simple "run Fuseki" script for docker: > (may need local variation e.g volume) > > "localhost" works in this variation. > > ----------------------------------------- > #!/bin/bash > > # Installation directory : change as needed. > DIR="....../apache-jena-fuseki-2.3.0" > # Caution: --net=host > > docker run -it --name Fuseki2 \ > -v ${DIR}:/fuseki \ > --net=host \ > java:8 \ > env FUSEKI_HOME=/fuseki /fuseki/fuseki-server --update --mem /ds > ----------------------------------------- -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
