Dave Meikle commented on TIKA-1518:

It is a choice we have to make. There are three mains routes to Docker 
packaging that I have used:
 # Automated builds that pull in pre-packaged and then get bundled into an 
image on any change in the an repository - like what we are doing n 
docker-tikaserver approach where is goes and downloads the signed JARs
 # Automated builds that compile the code in the image (e.g. using the maven 
Docker image) and then package them
 # Building a release image and then distributing that - which is what this 
does but requires us to decide when an official release is available and push 
it somewhere

The first and second are really good for leveraging things like Docker Hub to 
automatically build from your repository, where as the third means you have to 
have Docker on your machine when you want to build an image.

I never really like number two as it means the builds are always recompiles of 
the code each time a change is triggered, so you can easily be packing up 
different code as the same version without realising it.

The challenge with the approach in docker-tikaserver is maintaining when assets 
that are being pulled in move - i.e. when an release JAR is move from 
dist.apache.org - but that could easily be solved by going to Nexus for the 
JARs based on the release packages.

I personally quite like the third approach as it means you explicit create an 
image that has its own life and was thinking that we could potentially add this 
to the release process, pushing the image from the release build to Docker 
Hub/Nexus/Another Repos so it is an official build.

Not sure what others think?

> Docker with Tika Server
> -----------------------
>                 Key: TIKA-1518
>                 URL: https://issues.apache.org/jira/browse/TIKA-1518
>             Project: Tika
>          Issue Type: New Feature
>            Reporter: Paul Ramirez
>            Assignee: Dave Meikle
>            Priority: Major
>             Fix For: 2.0, 1.17
>         Attachments: tika-server-docker-err-msg.txt
> This version should be able to demonstrate as many of Apache Tika's 
> capabilities as possible. For instance with GDAL, Tesseract, and FFmpeg to 
> show parsers which require installation of other dependencies. In addition, 
> this should help move TIKA-1301 forward and should leverage the suggestion 
> made by [~lewismc] of a script which can pull down the latest version of 
> Apache Tika.

This message was sent by Atlassian JIRA

Reply via email to