[jira] [Updated] (TIKA-4232) Create and execute unit tests for tika-helm

2024-05-10 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-4232:
---
Fix Version/s: 2.9.3

> Create and execute unit tests for tika-helm
> ---
>
> Key: TIKA-4232
> URL: https://issues.apache.org/jira/browse/TIKA-4232
> Project: Tika
>  Issue Type: Improvement
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.9.3
>
>
> The goal is to execute chart unit tests against each tika-helm pull request.
> I found the [Helm Unit 
> Tests|[https://github.com/marketplace/actions/helm-unit-tests]] GitHub Action 
> which uses [https://github.com/helm-unittest/helm-unittest] as a Helm plugin.
> The PR will consist of one or more unit tests automated via the GitHub action.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TIKA-4232) Create and execute unit tests for tika-helm

2024-05-10 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-4232.

Resolution: Fixed

> Create and execute unit tests for tika-helm
> ---
>
> Key: TIKA-4232
> URL: https://issues.apache.org/jira/browse/TIKA-4232
> Project: Tika
>  Issue Type: Improvement
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
>
> The goal is to execute chart unit tests against each tika-helm pull request.
> I found the [Helm Unit 
> Tests|[https://github.com/marketplace/actions/helm-unit-tests]] GitHub Action 
> which uses [https://github.com/helm-unittest/helm-unittest] as a Helm plugin.
> The PR will consist of one or more unit tests automated via the GitHub action.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (TIKA-4232) Create and execute unit tests for tika-helm

2024-05-10 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney closed TIKA-4232.
--

> Create and execute unit tests for tika-helm
> ---
>
> Key: TIKA-4232
> URL: https://issues.apache.org/jira/browse/TIKA-4232
> Project: Tika
>  Issue Type: Improvement
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.9.3
>
>
> The goal is to execute chart unit tests against each tika-helm pull request.
> I found the [Helm Unit 
> Tests|[https://github.com/marketplace/actions/helm-unit-tests]] GitHub Action 
> which uses [https://github.com/helm-unittest/helm-unittest] as a Helm plugin.
> The PR will consist of one or more unit tests automated via the GitHub action.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (TIKA-4233) Check tika-helm for deprecated k8s APIs

2024-05-09 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney closed TIKA-4233.
--

> Check tika-helm for deprecated k8s APIs
> ---
>
> Key: TIKA-4233
> URL: https://issues.apache.org/jira/browse/TIKA-4233
> Project: Tika
>  Issue Type: New Feature
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.9.3
>
>
> It is useful to know when a Helm Chart uses deprecated k8s APIs. A check for 
> this would be ideal. The “Check deprecated k8s APIs” GitHub action 
> accomplishes this.
> [https://github.com/marketplace/actions/check-deprecated-k8s-apis]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TIKA-4233) Check tika-helm for deprecated k8s APIs

2024-05-09 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-4233.

Resolution: Fixed

This PR broke one of the GitHub Action workflows. I have written to INFRA about 
it

https://issues.apache.org/jira/browse/INFRA-25775

> Check tika-helm for deprecated k8s APIs
> ---
>
> Key: TIKA-4233
> URL: https://issues.apache.org/jira/browse/TIKA-4233
> Project: Tika
>  Issue Type: New Feature
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.9.3
>
>
> It is useful to know when a Helm Chart uses deprecated k8s APIs. A check for 
> this would be ideal. The “Check deprecated k8s APIs” GitHub action 
> accomplishes this.
> [https://github.com/marketplace/actions/check-deprecated-k8s-apis]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-4233) Check tika-helm for deprecated k8s APIs

2024-05-09 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-4233:
---
Fix Version/s: 2.9.3

> Check tika-helm for deprecated k8s APIs
> ---
>
> Key: TIKA-4233
> URL: https://issues.apache.org/jira/browse/TIKA-4233
> Project: Tika
>  Issue Type: New Feature
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.9.3
>
>
> It is useful to know when a Helm Chart uses deprecated k8s APIs. A check for 
> this would be ideal. The “Check deprecated k8s APIs” GitHub action 
> accomplishes this.
> [https://github.com/marketplace/actions/check-deprecated-k8s-apis]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-4232) Create and execute unit tests for tika-helm

2024-04-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835077#comment-17835077
 ] 

Lewis John McGibbney commented on TIKA-4232:


It turns out that the original GitHub action I wanted to use will  not be 
approved to use. 

I’m therefore investigating running the tests via the 
[https://github.com/marketplace/actions/docker-run-action] to run the 
{{{}helmunittest/helm-unittest Docker image{}}},  and generate the junit report 
and then using the [https://github.com/marketplace/actions/junit-report-action] 
to report the tests to the PR. 

 

I’ll do further investigation and followup here. 

> Create and execute unit tests for tika-helm
> ---
>
> Key: TIKA-4232
> URL: https://issues.apache.org/jira/browse/TIKA-4232
> Project: Tika
>  Issue Type: Improvement
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
>
> The goal is to execute chart unit tests against each tika-helm pull request.
> I found the [Helm Unit 
> Tests|[https://github.com/marketplace/actions/helm-unit-tests]] GitHub Action 
> which uses [https://github.com/helm-unittest/helm-unittest] as a Helm plugin.
> The PR will consist of one or more unit tests automated via the GitHub action.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: [ANNOUNCE] Apache Tika 2.9.2 released

2024-04-02 Thread lewis john mcgibbney
All good.
I’m looking into a way to just automate the Helm Chart release based on a
Webhook payload every time a new Docker container image is pushed to
DockerHub.
That would simplify things some…


On Tue, Apr 2, 2024 at 12:24 Tim Allison  wrote:

> Oops:
> https://cwiki.apache.org/confluence/display/TIKA/Release+Process+for+tika-helm
>
> Help...
>
> On Tue, Apr 2, 2024 at 3:22 PM Tim Allison  wrote:
> >
> > I did a global and thoughtless find/replace. Please review and merge
> > if this makes sense: https://github.com/apache/tika-helm/pull/19
> >
> > cc @lewis john mcgibbney
> >
> > On Tue, Apr 2, 2024 at 3:09 PM Tim Allison  wrote:
> > >
> > > I also released our docker images for 2.9.2.0.
> > >
> > > How do we update helm?
> > >
> > > On Tue, Apr 2, 2024 at 2:31 PM Tim Allison 
> wrote:
> > > >
> > > > The Apache Tika project is pleased to announce the release of Apache
> > > > Tika 2.9.2. The release contents have been pushed out to the main
> > > > Apache release site and to the Maven Central sync.
> > > >
> > > > Apache Tika is a toolkit for detecting and extracting metadata and
> > > > structured text content from various documents using existing parser
> > > > libraries.
> > > >
> > > > Apache Tika 2.9.2 includes numerous bug fixes and dependency
> upgrades.
> > > > Details can be found in the changes file:
> > > > https://www.apache.org/dist/tika/2.9.2/CHANGES-2.9.2.txt
> > > >
> > > > Apache Tika is available on the download page:
> > > > https://tika.apache.org/download.html
> > > >
> > > > Apache Tika is also available in binary form or for use using Maven 2
> > > > from the Central Repository:
> > > > https://repo1.maven.org/maven2/org/apache/tika/
> > > >
> > > > When downloading, please remember to verify the downloads using
> > > > signatures found: https://www.apache.org/dist/tika/KEYS
> > > >
> > > > For more information on Apache Tika, visit the project home page:
> > > > https://tika.apache.org/
> > > >
> > > > -- Tim Allison, on behalf of the Apache Tika community
>


[jira] [Created] (TIKA-4233) Check tika-helm for deprecated k8s APIs

2024-03-30 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-4233:
--

 Summary: Check tika-helm for deprecated k8s APIs
 Key: TIKA-4233
 URL: https://issues.apache.org/jira/browse/TIKA-4233
 Project: Tika
  Issue Type: New Feature
  Components: tika-helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.9.2


It is useful to know when a Helm Chart uses deprecated k8s APIs. A check for 
this would be ideal. The “Check deprecated k8s APIs” GitHub action accomplishes 
this.

[https://github.com/marketplace/actions/check-deprecated-k8s-apis]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TIKA-4232) Create and execute unit tests for tika-helm

2024-03-30 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-4232:
--

 Summary: Create and execute unit tests for tika-helm
 Key: TIKA-4232
 URL: https://issues.apache.org/jira/browse/TIKA-4232
 Project: Tika
  Issue Type: Improvement
  Components: tika-helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.9.2


The goal is to execute chart unit tests against each tika-helm pull request.

I found the [Helm Unit 
Tests|[https://github.com/marketplace/actions/helm-unit-tests]] GitHub Action 
which uses [https://github.com/helm-unittest/helm-unittest] as a Helm plugin.

The PR will consist of one or more unit tests automated via the GitHub action.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-4227) Register tika-helm Chart in artifacthub.io

2024-03-30 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832505#comment-17832505
 ] 

Lewis John McGibbney commented on TIKA-4227:


Available at [https://artifacthub.io/packages/helm/apache-tika/tika]

> Register tika-helm Chart in artifacthub.io
> --
>
> Key: TIKA-4227
> URL: https://issues.apache.org/jira/browse/TIKA-4227
> Project: Tika
>  Issue Type: Task
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
> Fix For: 2.9.2
>
>
> [https://artifacthub.io/] represents the most popular search interface for 
> (amongst lots of other artifacts) Helm Charts.
> This task will register the tika-helm Chart with [https://artifacthub.io/].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TIKA-4227) Register tika-helm Chart in artifacthub.io

2024-03-30 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-4227.

Resolution: Fixed

> Register tika-helm Chart in artifacthub.io
> --
>
> Key: TIKA-4227
> URL: https://issues.apache.org/jira/browse/TIKA-4227
> Project: Tika
>  Issue Type: Task
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
> Fix For: 2.9.2
>
>
> [https://artifacthub.io/] represents the most popular search interface for 
> (amongst lots of other artifacts) Helm Charts.
> This task will register the tika-helm Chart with [https://artifacthub.io/].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (TIKA-4227) Register tika-helm Chart in artifacthub.io

2024-03-30 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney closed TIKA-4227.
--

> Register tika-helm Chart in artifacthub.io
> --
>
> Key: TIKA-4227
> URL: https://issues.apache.org/jira/browse/TIKA-4227
> Project: Tika
>  Issue Type: Task
>  Components: tika-helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
> Fix For: 2.9.2
>
>
> [https://artifacthub.io/] represents the most popular search interface for 
> (amongst lots of other artifacts) Helm Charts.
> This task will register the tika-helm Chart with [https://artifacthub.io/].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


tika-helm now on artifacthub.io

2024-03-30 Thread lewis john mcgibbney
Hi user@, dev@,

For those running Tika on Kubernetes, you can now conveniently find the
Helm Chart via artifacthub.io

https://artifacthub.io/packages/helm/apache-tika/tika

I’ll build in a little more automation so that this thing just takes care
of itself.

Thanks to all contributors.

lewismc


[jira] [Created] (TIKA-4227) Register tika-helm Chart in artifacthub.io

2024-03-26 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-4227:
--

 Summary: Register tika-helm Chart in artifacthub.io
 Key: TIKA-4227
 URL: https://issues.apache.org/jira/browse/TIKA-4227
 Project: Tika
  Issue Type: Task
  Components: tika-helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.9.2


[https://artifacthub.io/] represents the most popular search interface for 
(amongst lots of other artifacts) Helm Charts.

This task will register the tika-helm Chart with [https://artifacthub.io/].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: Tika chart cannot be reached

2024-03-26 Thread Lewis John McGibbney
Hi Pietro,

On 2024/03/26 08:13:39 Pietro Susca wrote:

> 
> Francesco request's is that repo url in not working
> also tika is not searchable on the helm repo hub

Do you mean here - https://artifacthub.io/ ?
If you want it to be searchable via that platform then i can try to make an 
entry.

If there are any other problems with the Chart then please let me know.

Ciao
lewismc


Re: Tika chart cannot be reached

2024-03-26 Thread Lewis John McGibbney
Hi Francesco,
Thanks for letting us know that the repository was unreachable… I can only 
conclude that this was intermittent.
I can easily fetch and deploy the Chart as follows

helm repo add tika https://apache.jfrog.io/artifactory/tika
helm install tika tika/tika --set image.tag=latest-full -n tika-test

Thanks
lewismc

On 2024/03/25 12:16:31 Francesco Scuccimarri wrote:
> Hi Team Dev Tika,
> Over the past few days, I've encountered an issue while trying to use
> tika-helm . When I attempt to add the
> repository for Tika charts using the Helm command, I receive the following
> error message:
> 
> *Looks like 'https://apache.jfrog.io/artifactory/tika/
> ' is not a valid chart
> repository or cannot be reached.*
> 
> It seems that the issue is specific to the Tika chart repository.
> Do you have any updates regarding any changes to the Tika chart repository
> or its accessibility? I've reviewed the documentation and searched online,
> but I haven't found any recent information about this issue.
> 
> Thank you very much for your support.
> 
> Best regards,
> Francesco Scuccimarri
> 


[jira] [Updated] (TIKA-4169) Create a parser for Functional Mockup Unit (FMU) media type with .fmu extension

2023-11-13 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-4169:
---
Description: 
An Functional Mockup Unit (FMU) is a software component used for exchanging and 
simulating dynamic system models. It is designed to enable simulations of 
system models regardless of the simulation tool, programming language, or 
hardware platform. This is made possible through a standard interface that 
allows FMUs to be exported and imported across different simulation 
environments.

The FMU media type ships with the .fmu file suffix

I think the MIT licensed [NTNU-IHB/FMI4j|https://github.com/NTNU-IHB/FMI4j] can 
be used as the underlying parser implementation.

I will go on the hunt for some sample files we can use in unit tests. I think 
we can make some available via 
[https://github.com/Open-MBEE/perseverance-modelica]

  was:
An Functional Mockup Unit (FMU) is a software component used for exchanging and 
simulating dynamic system models. It is designed to enable simulations of 
system models regardless of the simulation tool, programming language, or 
hardware platform. This is made possible through a standard interface that 
allows FMUs to be exported and imported across different simulation 
environments.

The FMU media type ships with the .fmu file suffix

I think the MIT licensed [NTNU-IHB/FMI4j|https://github.com/NTNU-IHB/FMI4j] can 
be used as the underlying parser implementation.


> Create a parser for Functional Mockup Unit (FMU) media type with .fmu 
> extension
> ---
>
> Key: TIKA-4169
> URL: https://issues.apache.org/jira/browse/TIKA-4169
> Project: Tika
>  Issue Type: New Feature
>  Components: parser
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
>
> An Functional Mockup Unit (FMU) is a software component used for exchanging 
> and simulating dynamic system models. It is designed to enable simulations of 
> system models regardless of the simulation tool, programming language, or 
> hardware platform. This is made possible through a standard interface that 
> allows FMUs to be exported and imported across different simulation 
> environments.
> The FMU media type ships with the .fmu file suffix
> I think the MIT licensed [NTNU-IHB/FMI4j|https://github.com/NTNU-IHB/FMI4j] 
> can be used as the underlying parser implementation.
> I will go on the hunt for some sample files we can use in unit tests. I think 
> we can make some available via 
> [https://github.com/Open-MBEE/perseverance-modelica]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-4169) Create a parser for Functional Mockup Unit (FMU) media type with .fmu extension

2023-11-13 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-4169:
---
Description: 
An Functional Mockup Unit (FMU) is a software component used for exchanging and 
simulating dynamic system models. It is designed to enable simulations of 
system models regardless of the simulation tool, programming language, or 
hardware platform. This is made possible through a standard interface that 
allows FMUs to be exported and imported across different simulation 
environments.

The FMU media type ships with the .fmu file suffix

I think the MIT licensed [NTNU-IHB/FMI4j|https://github.com/NTNU-IHB/FMI4j] can 
be used as the underlying parser implementation.

  was:
An Functional Mockup Unit (FMU) is a software component used for exchanging and 
simulating dynamic system models. It is designed to enable simulations of 
system models regardless of the simulation tool, programming language, or 
hardware platform. This is made possible through a standard interface that 
allows FMUs to be exported and imported across different simulation 
environments.

 

The FMU media type ships with the .fmu file suffix 

 

I think the MIT licensed [NTNU-IHB/FMI4j|[https://github.com/NTNU-IHB/FMI4j]] 
can be used as the underlying parser implementation.


> Create a parser for Functional Mockup Unit (FMU) media type with .fmu 
> extension
> ---
>
> Key: TIKA-4169
> URL: https://issues.apache.org/jira/browse/TIKA-4169
> Project: Tika
>  Issue Type: New Feature
>  Components: parser
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
>
> An Functional Mockup Unit (FMU) is a software component used for exchanging 
> and simulating dynamic system models. It is designed to enable simulations of 
> system models regardless of the simulation tool, programming language, or 
> hardware platform. This is made possible through a standard interface that 
> allows FMUs to be exported and imported across different simulation 
> environments.
> The FMU media type ships with the .fmu file suffix
> I think the MIT licensed [NTNU-IHB/FMI4j|https://github.com/NTNU-IHB/FMI4j] 
> can be used as the underlying parser implementation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TIKA-4169) Create a parser for Functional Mockup Unit (FMU) media type with .fmu extension

2023-11-13 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-4169:
--

 Summary: Create a parser for Functional Mockup Unit (FMU) media 
type with .fmu extension
 Key: TIKA-4169
 URL: https://issues.apache.org/jira/browse/TIKA-4169
 Project: Tika
  Issue Type: New Feature
  Components: parser
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney


An Functional Mockup Unit (FMU) is a software component used for exchanging and 
simulating dynamic system models. It is designed to enable simulations of 
system models regardless of the simulation tool, programming language, or 
hardware platform. This is made possible through a standard interface that 
allows FMUs to be exported and imported across different simulation 
environments.

 

The FMU media type ships with the .fmu file suffix 

 

I think the MIT licensed [NTNU-IHB/FMI4j|[https://github.com/NTNU-IHB/FMI4j]] 
can be used as the underlying parser implementation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-3989) Upgrade tika-helm Horizontal Pod Autoscaling from to autoscaling/v2beta1 to autoscaling/v2

2023-03-20 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3989:
---
Description: The _*autoscaling/v2beta1*_ API is superseded with 
{_}*autoscaling/v2*{_}. This is documented thoroughly at 
[https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/]
  (was: The _*autoscaling/v2beta1*_ API is superseded with autoscaling/v2. This 
is documented thoroughly at 
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)

> Upgrade tika-helm Horizontal Pod Autoscaling from to autoscaling/v2beta1 to 
> autoscaling/v2
> --
>
> Key: TIKA-3989
> URL: https://issues.apache.org/jira/browse/TIKA-3989
> Project: Tika
>  Issue Type: Task
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
>
> The _*autoscaling/v2beta1*_ API is superseded with {_}*autoscaling/v2*{_}. 
> This is documented thoroughly at 
> [https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TIKA-3989) Upgrade tika-helm Horizontal Pod Autoscaling from to autoscaling/v2beta1 to autoscaling/v2

2023-03-20 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3989:
--

 Summary: Upgrade tika-helm Horizontal Pod Autoscaling from to 
autoscaling/v2beta1 to autoscaling/v2
 Key: TIKA-3989
 URL: https://issues.apache.org/jira/browse/TIKA-3989
 Project: Tika
  Issue Type: Task
  Components: helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney


The _*autoscaling/v2beta1*_ API is superseded with autoscaling/v2. This is 
documented thoroughly in 

[https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/|https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-3989) Upgrade tika-helm Horizontal Pod Autoscaling from to autoscaling/v2beta1 to autoscaling/v2

2023-03-20 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3989:
---
Description: The _*autoscaling/v2beta1*_ API is superseded with 
autoscaling/v2. This is documented thoroughly at 
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
  (was: The _*autoscaling/v2beta1*_ API is superseded with autoscaling/v2. This 
is documented thoroughly in 

[https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/|https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)

> Upgrade tika-helm Horizontal Pod Autoscaling from to autoscaling/v2beta1 to 
> autoscaling/v2
> --
>
> Key: TIKA-3989
> URL: https://issues.apache.org/jira/browse/TIKA-3989
> Project: Tika
>  Issue Type: Task
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Minor
>
> The _*autoscaling/v2beta1*_ API is superseded with autoscaling/v2. This is 
> documented thoroughly at 
> https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (TIKA-3988) Add Github Action to Lint and Test Charts

2023-03-20 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney closed TIKA-3988.
--

> Add Github Action to Lint and Test Charts
> -
>
> Key: TIKA-3988
> URL: https://issues.apache.org/jira/browse/TIKA-3988
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>Affects Versions: 2.7.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> The [chart-testing-action|https://github.com/helm/chart-testing-action] will 
> improve CI for the tika-helm. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TIKA-3988) Add Github Action to Lint and Test Charts

2023-03-20 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3988.

Resolution: Fixed

> Add Github Action to Lint and Test Charts
> -
>
> Key: TIKA-3988
> URL: https://issues.apache.org/jira/browse/TIKA-3988
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>Affects Versions: 2.7.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> The [chart-testing-action|https://github.com/helm/chart-testing-action] will 
> improve CI for the tika-helm. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[ANNOUNCEMENT] Apache Tika Helm Chart v2.7.0 and v2.7.0-full released

2023-03-19 Thread lewis john mcgibbney
The Tika PMC is happy to announce that tika-helm v2.7.0 and
v2.7.0-full Charts are now available.

Documentation can be found at https://github.com/apache/tika-helm#readme

Please register support and feedback at
https://github.com/apache/tika-helm/pulls

Thanks to everyone who contributed to these releases.

Happy Helm'ing...

lewismc

-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


[jira] [Commented] (TIKA-3988) Add Github Action to Lint and Test Charts

2023-03-19 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702421#comment-17702421
 ] 

Lewis John McGibbney commented on TIKA-3988:


It looks like there are some permissions issues which needs to be configured 
before the Github action can be run. I got in touch with INFRA about this. The 
Github Action output is as follows
{quote}
Error: .github#L1
helm/chart-testing-action@v2.3.1 and helm/kind-action@v1.4.0 are not allowed to 
be used in apache/tika-helm. Actions in this workflow must be: within a 
repository owned by apache, created by GitHub, verified in the GitHub 
Marketplace, or matching the following: 
{*}/{*}@[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]+, 
AdoptOpenJDK/install-jdk@{*}, 
JamesIves/github-pages-deploy-action@5dc1d5a192aeb5ab5b7d5a77b7d36aea4a7f5c92, 
TobKed/label-when-approved-action@{*}, actions-cool/issues-helper@{*}, 
actions-rs/{*}, al-cheb/configure-pagefile-action@{*}, 
amannn/action-semantic-pull-request@{*}, apache/{*}, 
burrunan/gradle-cache-action@{*}, bytedeco/javacpp-presets/.github/actions/{*}, 
chromaui/action@{*}, codecov/codecov-action@{*}, 
conda-incubator/setup-miniconda@{*}, container-tools/kind-action@{*}, 
container-tools/microshift-action@{*}, dawidd6/action-download-artifact@{*}, 
delaguardo/setup-graalvm@{*}, docker://jekyll/jekyll:{*}, 
docker://pandoc/core:2.9, eps1lon/actions-label-merge-conflict@{*}, 
gaurav-nelson/gith...
{quote}

> Add Github Action to Lint and Test Charts
> -
>
> Key: TIKA-3988
> URL: https://issues.apache.org/jira/browse/TIKA-3988
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>Affects Versions: 2.7.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> The [chart-testing-action|https://github.com/helm/chart-testing-action] will 
> improve CI for the tika-helm. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TIKA-3988) Add Github Action to Lint and Test Charts

2023-03-19 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3988:
--

 Summary: Add Github Action to Lint and Test Charts
 Key: TIKA-3988
 URL: https://issues.apache.org/jira/browse/TIKA-3988
 Project: Tika
  Issue Type: Improvement
  Components: helm
Affects Versions: 2.7.0
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.7.0


The [chart-testing-action|https://github.com/helm/chart-testing-action] will 
improve CI for the tika-helm. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3985) Automate tika-helm Chart releases with helm/chart-releaser-action

2023-03-19 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702402#comment-17702402
 ] 

Lewis John McGibbney commented on TIKA-3985:


https://github.com/marketplace/actions/jfrog-cli-for-github-actions
https://github.com/helm/chart-releaser-action

> Automate tika-helm Chart releases with helm/chart-releaser-action 
> --
>
> Key: TIKA-3985
> URL: https://issues.apache.org/jira/browse/TIKA-3985
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> I've received several requests for 
> [tika-helm|https://github.com/apache/tika-helm] releases to shadow 
> [tika-docker|https://github.com/apache/tika-docker].
> I found a Github action which will enable that. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TIKA-3985) Automate tika-helm Chart releases with helm/chart-releaser-action

2023-03-10 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3985:
--

 Summary: Automate tika-helm Chart releases with 
helm/chart-releaser-action 
 Key: TIKA-3985
 URL: https://issues.apache.org/jira/browse/TIKA-3985
 Project: Tika
  Issue Type: Improvement
  Components: helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.7.0


I've received several requests for 
[tika-helm|https://github.com/apache/tika-helm] releases to shadow 
[tika-docker|https://github.com/apache/tika-docker].
I found a Github action which will enable that. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-3452) java.nio.file.FileSystemException Read-only file system

2023-03-03 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3452:
---
Fix Version/s: 2.7.0
   (was: 2.0.0-BETA)

> java.nio.file.FileSystemException Read-only file system
> ---
>
> Key: TIKA-3452
> URL: https://issues.apache.org/jira/browse/TIKA-3452
> Project: Tika
>  Issue Type: Bug
>  Components: docker, helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> The following ExecutionException is thrown when I attempt to run [tika-docker 
> 2.0.0-BETA|https://hub.docker.com/layers/apache/tika/2.0.0-BETA-full/images/sha256-2d735f7bdf86e618a5390d92614a310697f9134d11a2b2e4c1c0cfcde1f68b1d?context=explore]
> {code:bash}
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> java.util.concurrent.ExecutionException: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>   at 
> org.apache.tika.server.core.TikaServerCli.mainLoop(TikaServerCli.java:116)
>   at 
> org.apache.tika.server.core.TikaServerCli.execute(TikaServerCli.java:88)
>   at org.apache.tika.server.core.TikaServerCli.main(TikaServerCli.java:66)
> Caused by: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:375)
>   at java.base/java.nio.file.Files.createFile(Files.java:652)
>   at 
> java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:137)
>   at 
> java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:160)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:917)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:220)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:210)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:117)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:50)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>   at java.base/java.lang.Thread.run(Thread.java:832)
> {code}
> There are differences/improvements in the way the [tika-server child process 
> is 
> spawned|https://cwiki.apache.org/confluence/display/TIKA/TikaServer#TikaServer-MakingTikaServerRobusttoOOMs,InfiniteLoopsandMemoryLeaks]
>  in the 2.0.0-BETA docker image. I am investigating a fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TIKA-3452) java.nio.file.FileSystemException Read-only file system

2023-03-03 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3452.

Resolution: Fixed

> java.nio.file.FileSystemException Read-only file system
> ---
>
> Key: TIKA-3452
> URL: https://issues.apache.org/jira/browse/TIKA-3452
> Project: Tika
>  Issue Type: Bug
>  Components: docker, helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.7.0
>
>
> The following ExecutionException is thrown when I attempt to run [tika-docker 
> 2.0.0-BETA|https://hub.docker.com/layers/apache/tika/2.0.0-BETA-full/images/sha256-2d735f7bdf86e618a5390d92614a310697f9134d11a2b2e4c1c0cfcde1f68b1d?context=explore]
> {code:bash}
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> java.util.concurrent.ExecutionException: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>   at 
> org.apache.tika.server.core.TikaServerCli.mainLoop(TikaServerCli.java:116)
>   at 
> org.apache.tika.server.core.TikaServerCli.execute(TikaServerCli.java:88)
>   at org.apache.tika.server.core.TikaServerCli.main(TikaServerCli.java:66)
> Caused by: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:375)
>   at java.base/java.nio.file.Files.createFile(Files.java:652)
>   at 
> java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:137)
>   at 
> java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:160)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:917)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:220)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:210)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:117)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:50)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>   at java.base/java.lang.Thread.run(Thread.java:832)
> {code}
> There are differences/improvements in the way the [tika-server child process 
> is 
> spawned|https://cwiki.apache.org/confluence/display/TIKA/TikaServer#TikaServer-MakingTikaServerRobusttoOOMs,InfiniteLoopsandMemoryLeaks]
>  in the 2.0.0-BETA docker image. I am investigating a fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TIKA-3452) java.nio.file.FileSystemException Read-only file system

2023-02-15 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3452:
---
Summary: java.nio.file.FileSystemException Read-only file system  (was: 
java.nio.file.FileSystemException Read-only file system in 2.0.0-BETA 
tika-docker)

> java.nio.file.FileSystemException Read-only file system
> ---
>
> Key: TIKA-3452
> URL: https://issues.apache.org/jira/browse/TIKA-3452
> Project: Tika
>  Issue Type: Bug
>  Components: docker, helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.0.0-BETA
>
>
> The following ExecutionException is thrown when I attempt to run [tika-docker 
> 2.0.0-BETA|https://hub.docker.com/layers/apache/tika/2.0.0-BETA-full/images/sha256-2d735f7bdf86e618a5390d92614a310697f9134d11a2b2e4c1c0cfcde1f68b1d?context=explore]
> {code:bash}
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
> details.
> java.util.concurrent.ExecutionException: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>   at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
>   at 
> org.apache.tika.server.core.TikaServerCli.mainLoop(TikaServerCli.java:116)
>   at 
> org.apache.tika.server.core.TikaServerCli.execute(TikaServerCli.java:88)
>   at org.apache.tika.server.core.TikaServerCli.main(TikaServerCli.java:66)
> Caused by: java.nio.file.FileSystemException: 
> /tmp/apache-tika-server-forked-tmp-8374629799942405236: Read-only file system
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
>   at java.base/java.nio.file.Files.newByteChannel(Files.java:375)
>   at java.base/java.nio.file.Files.createFile(Files.java:652)
>   at 
> java.base/java.nio.file.TempFileHelper.create(TempFileHelper.java:137)
>   at 
> java.base/java.nio.file.TempFileHelper.createTempFile(TempFileHelper.java:160)
>   at java.base/java.nio.file.Files.createTempFile(Files.java:917)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:220)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.(TikaServerWatchDog.java:210)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:117)
>   at 
> org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:50)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
>   at java.base/java.lang.Thread.run(Thread.java:832)
> {code}
> There are differences/improvements in the way the [tika-server child process 
> is 
> spawned|https://cwiki.apache.org/confluence/display/TIKA/TikaServer#TikaServer-MakingTikaServerRobusttoOOMs,InfiniteLoopsandMemoryLeaks]
>  in the 2.0.0-BETA docker image. I am investigating a fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-2536) Move to later edu.ucar version to avoid EOL dependencies

2022-11-02 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628032#comment-17628032
 ] 

Lewis John McGibbney commented on TIKA-2536:


The may appreciate a contribution which allows them to [accommodate dual 
publication|https://docs.unidata.ucar.edu/netcdf-java/current/userguide/building_from_source.html#publishing].
 If you can look at the question above [~nick], then I'll go ahead and ask. 
I'm trying to anticipate them asking why we can't just reference their 
repository...

> Move to later edu.ucar version to avoid EOL dependencies
> 
>
> Key: TIKA-2536
> URL: https://issues.apache.org/jira/browse/TIKA-2536
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 1.16, 1.17
> Environment: All
>Reporter: Richard Jones
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> The currently referenced 4.5.5 versions of edu.ucar:grib and edu.ucar:cdm 
> (released in Mar 2015), as well as being branch EOL themselves, depend on 
> many other project/branch/version EOL artifacts for which much later and 
> active versions are often available. The list is as follows:
> - edu.ucar:grib depends on the project EOL bzip2. Much more recent versions 
> of edu.ucar:grib exist that no longer depend on bzip2 (note: Jbzip2 is hosted 
> on the Google Code site, which was shut down for active development in 2015.  
> The project was never migrated to another site, e.g. Github).
> - edu.ucar:grib depends on the 2.0.4 EOL version of org.jdom:jdom2
> - edu.ucar:cdm depends on the 2.6.2 branch EOL version of 
> net.sf.ehcache:ehcache-core
> - edu.ucar:cdm depends on the 2.2.0 EOL version of 
> org.quartz-scheduler:quartz for which active versions are available. In turn 
> org.quartz-scheduler:quartz depends on the 0.9.1.1 branch EOL version of 
> c3p0:c3p0. Later versions of quartz have moved to the active com.mchange:c3p0
> - edu.ucar:grib depends on the 2.5.0 branch EOL version of 
> com.google.protobuf:protobuf-java for which active versions are available.
> Request moving to a much later version of edu.ucar, or alternative artifacts 
> to address all the above EOL issues (lack of active support for 
> vulnerabilities and bugs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (TIKA-2536) Move to later edu.ucar version to avoid EOL dependencies

2022-11-02 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628029#comment-17628029
 ] 

Lewis John McGibbney edited comment on TIKA-2536 at 11/3/22 12:36 AM:
--

As of version 5.0, netCDF-Java is released under the [BSD-3 
licence|https://github.com/Unidata/netcdf-java/blob/master/LICENSE]
* tika main branch relies on v4.5.5
* current netCDF-java release appears to be 5.5.2 

[~nick] I _think_ I used to know the answer to this question but it escapes me 
now. What conditions/restrictions result in the following statement  "...We can 
only depend on versions in maven central, we can't depend on versions hosted 
elsewhere"? Please remind me. Thanks


was (Author: lewismc):
As of version 5.0, netCDF-Java is released under the [BSD-3 
licence|https://github.com/Unidata/netcdf-java/blob/master/LICENSE]
* tika main branch relies on v4.5.5
* current netCDF-java release appears to be 5.5.2 

[~nick] I think I used to know the answer to this question but what 
conditions/restriuctions result in the following statement  "...We can only 
depend on versions in maven central, we can't depend on versions hosted 
elsewhere"? Please remind me. Thanks

> Move to later edu.ucar version to avoid EOL dependencies
> 
>
> Key: TIKA-2536
> URL: https://issues.apache.org/jira/browse/TIKA-2536
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 1.16, 1.17
> Environment: All
>Reporter: Richard Jones
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> The currently referenced 4.5.5 versions of edu.ucar:grib and edu.ucar:cdm 
> (released in Mar 2015), as well as being branch EOL themselves, depend on 
> many other project/branch/version EOL artifacts for which much later and 
> active versions are often available. The list is as follows:
> - edu.ucar:grib depends on the project EOL bzip2. Much more recent versions 
> of edu.ucar:grib exist that no longer depend on bzip2 (note: Jbzip2 is hosted 
> on the Google Code site, which was shut down for active development in 2015.  
> The project was never migrated to another site, e.g. Github).
> - edu.ucar:grib depends on the 2.0.4 EOL version of org.jdom:jdom2
> - edu.ucar:cdm depends on the 2.6.2 branch EOL version of 
> net.sf.ehcache:ehcache-core
> - edu.ucar:cdm depends on the 2.2.0 EOL version of 
> org.quartz-scheduler:quartz for which active versions are available. In turn 
> org.quartz-scheduler:quartz depends on the 0.9.1.1 branch EOL version of 
> c3p0:c3p0. Later versions of quartz have moved to the active com.mchange:c3p0
> - edu.ucar:grib depends on the 2.5.0 branch EOL version of 
> com.google.protobuf:protobuf-java for which active versions are available.
> Request moving to a much later version of edu.ucar, or alternative artifacts 
> to address all the above EOL issues (lack of active support for 
> vulnerabilities and bugs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-2536) Move to later edu.ucar version to avoid EOL dependencies

2022-11-02 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628029#comment-17628029
 ] 

Lewis John McGibbney commented on TIKA-2536:


As of version 5.0, netCDF-Java is released under the [BSD-3 
licence|https://github.com/Unidata/netcdf-java/blob/master/LICENSE]
* tika main branch relies on v4.5.5
* current netCDF-java release appears to be 5.5.2 

[~nick] I think I used to know the answer to this question but what 
conditions/restriuctions result in the following statement  "...We can only 
depend on versions in maven central, we can't depend on versions hosted 
elsewhere"? Please remind me. Thanks

> Move to later edu.ucar version to avoid EOL dependencies
> 
>
> Key: TIKA-2536
> URL: https://issues.apache.org/jira/browse/TIKA-2536
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 1.16, 1.17
> Environment: All
>Reporter: Richard Jones
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> The currently referenced 4.5.5 versions of edu.ucar:grib and edu.ucar:cdm 
> (released in Mar 2015), as well as being branch EOL themselves, depend on 
> many other project/branch/version EOL artifacts for which much later and 
> active versions are often available. The list is as follows:
> - edu.ucar:grib depends on the project EOL bzip2. Much more recent versions 
> of edu.ucar:grib exist that no longer depend on bzip2 (note: Jbzip2 is hosted 
> on the Google Code site, which was shut down for active development in 2015.  
> The project was never migrated to another site, e.g. Github).
> - edu.ucar:grib depends on the 2.0.4 EOL version of org.jdom:jdom2
> - edu.ucar:cdm depends on the 2.6.2 branch EOL version of 
> net.sf.ehcache:ehcache-core
> - edu.ucar:cdm depends on the 2.2.0 EOL version of 
> org.quartz-scheduler:quartz for which active versions are available. In turn 
> org.quartz-scheduler:quartz depends on the 0.9.1.1 branch EOL version of 
> c3p0:c3p0. Later versions of quartz have moved to the active com.mchange:c3p0
> - edu.ucar:grib depends on the 2.5.0 branch EOL version of 
> com.google.protobuf:protobuf-java for which active versions are available.
> Request moving to a much later version of edu.ucar, or alternative artifacts 
> to address all the above EOL issues (lack of active support for 
> vulnerabilities and bugs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-2536) Move to later edu.ucar version to avoid EOL dependencies

2022-11-02 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17628027#comment-17628027
 ] 

Lewis John McGibbney commented on TIKA-2536:


As [~nick] mentioned referencing 3rd-party artifact repos is a no-go. [UCAR 
provides documentation on the repos and how to do exactly 
that|https://docs.unidata.ucar.edu/netcdf-java/current/userguide/using_netcdf_java_artifacts.html]
 but that doesn't help us as we would need to reference their repos...

I will attempt to contact the UCAR team and see where I get... I'll write back 
here.



> Move to later edu.ucar version to avoid EOL dependencies
> 
>
> Key: TIKA-2536
> URL: https://issues.apache.org/jira/browse/TIKA-2536
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 1.16, 1.17
> Environment: All
>Reporter: Richard Jones
>Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> The currently referenced 4.5.5 versions of edu.ucar:grib and edu.ucar:cdm 
> (released in Mar 2015), as well as being branch EOL themselves, depend on 
> many other project/branch/version EOL artifacts for which much later and 
> active versions are often available. The list is as follows:
> - edu.ucar:grib depends on the project EOL bzip2. Much more recent versions 
> of edu.ucar:grib exist that no longer depend on bzip2 (note: Jbzip2 is hosted 
> on the Google Code site, which was shut down for active development in 2015.  
> The project was never migrated to another site, e.g. Github).
> - edu.ucar:grib depends on the 2.0.4 EOL version of org.jdom:jdom2
> - edu.ucar:cdm depends on the 2.6.2 branch EOL version of 
> net.sf.ehcache:ehcache-core
> - edu.ucar:cdm depends on the 2.2.0 EOL version of 
> org.quartz-scheduler:quartz for which active versions are available. In turn 
> org.quartz-scheduler:quartz depends on the 0.9.1.1 branch EOL version of 
> c3p0:c3p0. Later versions of quartz have moved to the active com.mchange:c3p0
> - edu.ucar:grib depends on the 2.5.0 branch EOL version of 
> com.google.protobuf:protobuf-java for which active versions are available.
> Request moving to a much later version of edu.ucar, or alternative artifacts 
> to address all the above EOL issues (lack of active support for 
> vulnerabilities and bugs).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TIKA-3826) Helm: use appVersion from Charts.yaml intsead of images.tag

2022-10-13 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617298#comment-17617298
 ] 

Lewis John McGibbney commented on TIKA-3826:


[~hairmare] good suggestion. Please file a PR and tage me. i will be happy to 
review.
Thanks

> Helm: use appVersion from Charts.yaml intsead of images.tag
> ---
>
> Key: TIKA-3826
> URL: https://issues.apache.org/jira/browse/TIKA-3826
> Project: Tika
>  Issue Type: Bug
>  Components: helm
>Affects Versions: 2.2.1
>Reporter: Lucas Bickel
>Priority: Major
>
> This is about the [tika Helm chart|https://github.com/apache/tika-helm].
> In `values.yaml` we currently have 
> [this|https://github.com/apache/tika-helm/blob/492386471616713bddbc5851912acdd78bd87609/values.yaml#L25-L26]:
> {code:yaml}
> # Overrides the image tag whose default is the chart appVersion.
>   tag: "1.26"
> {code}
> This leads to {{ .Values.image.tag | default .Chart.AppVersion }} [in 
> deployment.yaml|https://github.com/apache/tika-helm/blob/492386471616713bddbc5851912acdd78bd87609/templates/deployment.yaml#L52]
>  being dead code.
> Currently the docs indicate that we should set {{image.tag}} during the 
> deployment, skipping this step results in deploying a very outdated tika 1.26.
> My proposal for fixing this is to set the appVersion in {{Chart.yaml}} to the 
> latest 2.4.1-full version and set the image.tag to an empty version so it 
> defaults to the version from Chart.yaml.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: DockerHub access?

2022-10-06 Thread lewis john mcgibbney
Please remove me I DO NOT have the cycles right now.
lewismc

On Mon, Oct 3, 2022 at 09:33 Tim Allison  wrote:

> Fellow devs,
>   I'd like write access to docker hub.  According to [0], we can only
> have 2 accounts.  We currently have 3:
> chrismattmann
> dameikle
> lewismc
>
>   Would anyone who currently has access be willing to be removed? Or
> should I hold off on this request?
>
>   Thank you.
>
> Best,
>
>  Tim
>
> [0]
>
> https://issues.apache.org/jira/browse/INFRA-23739?focusedCommentId=17612357=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17612357
>
-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


Re: [DRAFT] Dedicated ANNOUNCE for Tika 1.x EoL?

2022-02-10 Thread Lewis John McGibbney
This looks great Tim.

On 2022/02/09 15:51:39 Tim Allison wrote:
> What do you think?
> 
> Subject: [ANNOUNCE] Apache Tika 1.x End-Of-Life (EOL) announcement
> 
> The Apache Tika Project Team would like to inform you that the Apache Tika
> 1.x branch is now in security-only maintenance until September 30, 2022.
> After that date, we will not make updates or releases from our 1.x branch.
> We will continue to make security fixes and security-related
> dependency upgrades in our 1.x branch as necessary until September 30,
> 2022.
> 
> We initially announced this on our website on December 16, 2021 with
> the release of Tika 2.2.0: https://tika.apache.org/
> 
> Questions and Answers:
> 
> With the announcement of Tika 1.x EoL, what happens to
> Tika 1.x resources?
> 
> All resources will stay where they are. Users will still
> be able to download source code from our branch_1x branch from
> github[1]; and published artifacts will remain available on
> maven central and in the Apache archives[2].
> 
> [1] https://github.com/apache/tika/tree/branch_1x
> [2] https://archive.apache.org/dist/tika/
> 
> Is there an immediate need to upgrade to Tika 2.x in my projects?
> 
> As of today, there aren't known vulnerabilities affecting the
> soon-to-be-released Tika 1.28.1.  However, considering that there are
> several breaking changes in the 2.x branch, we encourage making the
> migration soon to allow time to adjust your client code as
> necessary.  For up-to-date documentation on migrating to 2.x, see [3].
> 
> [3] https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0
> 
> My friends / colleagues and I would like to see Tika 1.x being
> maintained after September 30, 2022. What can we do?
> 
> You may fork the existing source and support it on your own.
> 
> Kind regards
> -
> The Apache Tika Team
> 
> On Wed, Feb 9, 2022 at 10:06 AM Tim Allison  wrote:
> >
> > +1
> >
> > And here's a model for what it could look like:
> > https://lists.apache.org/thread/zz3v90hd1ycrhfvy76n1crsn26sydhmq
> >
> > On Wed, Feb 9, 2022 at 10:03 AM lewis john mcgibbney  
> > wrote:
> > >
> > > Hi dev@,
> > > We have more than six months until the official EoL date for Tika 1.x.
> > > Tim mentioned that some narrative was provided in the the recent release
> > > announcement but I think we could help ourselves by explicitly sending a
> > > dedicated 1.x EoL ANNOUNCEMENT.
> > > … this assumes that such an email would be moderated through.
> > > I say it’s worth a bash.
> > > Any comments?
> > > Thanks
> > > lewismc
> > > --
> > > http://home.apache.org/~lewismc/
> > > http://people.apache.org/keys/committer/lewismc
> 


[jira] [Resolved] (TIKA-3648) Fail build if ossindex-maven-plugin violation is detected

2022-02-10 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3648.

Resolution: Fixed

With dependabot now activated our goal should be to keep things up-to-date. 

> Fail build if ossindex-maven-plugin violation is detected
> -
>
> Key: TIKA-3648
> URL: https://issues.apache.org/jira/browse/TIKA-3648
> Project: Tika
>  Issue Type: Improvement
>  Components: build, security
>Affects Versions: 2.2.1
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Critical
>
> The ossindex-maven-plugin can really assist us in detecting and preventing 
> security vulnerabilities and also mitigating associated risk and exposure.
> I propose to fail the build if ossindex-maven-plugin violation is detected
> https://github.com/apache/tika/blob/main/tika-parent/pom.xml#L639



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3648) Fail build if ossindex-maven-plugin violation is detected

2022-02-10 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3648:
---
Fix Version/s: 2.3.1

> Fail build if ossindex-maven-plugin violation is detected
> -
>
> Key: TIKA-3648
> URL: https://issues.apache.org/jira/browse/TIKA-3648
> Project: Tika
>  Issue Type: Improvement
>  Components: build, security
>Affects Versions: 2.2.1
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Critical
> Fix For: 2.3.1
>
>
> The ossindex-maven-plugin can really assist us in detecting and preventing 
> security vulnerabilities and also mitigating associated risk and exposure.
> I propose to fail the build if ossindex-maven-plugin violation is detected
> https://github.com/apache/tika/blob/main/tika-parent/pom.xml#L639



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


Dedicated ANNOUNCE for Tika 1.x EoL?

2022-02-09 Thread lewis john mcgibbney
Hi dev@,
We have more than six months until the official EoL date for Tika 1.x.
Tim mentioned that some narrative was provided in the the recent release
announcement but I think we could help ourselves by explicitly sending a
dedicated 1.x EoL ANNOUNCEMENT.
… this assumes that such an email would be moderated through.
I say it’s worth a bash.
Any comments?
Thanks
lewismc
-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


[jira] [Resolved] (TIKA-3566) Upgrade tika-helm to 2.2.1

2022-01-22 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3566.

Fix Version/s: 2.2.1
   (was: 2.1.0)
   Resolution: Fixed

Done. I made the announcements to the user@ and dev@ mailing lists.
I'm planning on writing a Jenkinsfile which will automate all of this in the 
future.

> Upgrade tika-helm to 2.2.1
> --
>
> Key: TIKA-3566
> URL: https://issues.apache.org/jira/browse/TIKA-3566
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Simple upgrade to tika-docker 2.2.1.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[RELEASE] Apache Tika Helm Chart 2.2.1 and 2.2.1-full

2022-01-22 Thread lewis john mcgibbney
Hi user@ and dev@,
I am happy to announce the release of tika-helm 2.2.1 [0] and 2.2.1-full
[1].
This Helm chart is a lightweight way to configure and run the official
apache/tika  Docker image.
Please see the README [2] for information on installation [3], etc.
Thank you
lewismc

[0] https://github.com/apache/tika-helm/releases/tag/2.2.1
[1] https://github.com/apache/tika-helm/releases/tag/2.2.1-full
[2] https://github.com/apache/tika-helm/blob/main/README.md
[3] https://github.com/apache/tika-helm/blob/main/README.md#installing

-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


[jira] [Updated] (TIKA-3566) Upgrade tika-helm to 2.2.1

2022-01-22 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3566:
---
Description: Simple upgrade to tika-docker 2.2.1.  (was: Simple upgrade to 
[tika-docker 
2.1.0|https://hub.docker.com/layers/apache/tika/2.1.0/images/sha256-5bb52afa9726cf2ca022441cc75ef357de9f8deb41a88a9b2964780e934d11e7?context=explore].)

> Upgrade tika-helm to 2.2.1
> --
>
> Key: TIKA-3566
> URL: https://issues.apache.org/jira/browse/TIKA-3566
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.0
>
>
> Simple upgrade to tika-docker 2.2.1.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3566) Upgrade tika-helm to 2.2.1

2022-01-22 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3566:
---
Summary: Upgrade tika-helm to 2.2.1  (was: Upgrade tika-helm to 2.1.0)

> Upgrade tika-helm to 2.2.1
> --
>
> Key: TIKA-3566
> URL: https://issues.apache.org/jira/browse/TIKA-3566
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.0
>
>
> Simple upgrade to [tika-docker 
> 2.1.0|https://hub.docker.com/layers/apache/tika/2.1.0/images/sha256-5bb52afa9726cf2ca022441cc75ef357de9f8deb41a88a9b2964780e934d11e7?context=explore].



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-3649) Perform findbugs static analysis on the project and address the issues

2022-01-19 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3649.

Resolution: Fixed

Thanks [~dkryukov]

> Perform findbugs static analysis on the project and address the issues
> --
>
> Key: TIKA-3649
> URL: https://issues.apache.org/jira/browse/TIKA-3649
> Project: Tika
>  Issue Type: Improvement
>Reporter: Dmitrii Kriukov
>Assignee: Dmitrii Kriukov
>Priority: Major
> Fix For: 2.2.2
>
>
> I'm going to create one PR per module of the project.
> The first one is https://github.com/apache/tika/pull/478



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Assigned] (TIKA-3649) Perform findbugs static analysis on the project and address the issues

2022-01-19 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney reassigned TIKA-3649:
--

Assignee: Dmitrii Kriukov

> Perform findbugs static analysis on the project and address the issues
> --
>
> Key: TIKA-3649
> URL: https://issues.apache.org/jira/browse/TIKA-3649
> Project: Tika
>  Issue Type: Improvement
>Reporter: Dmitrii Kriukov
>Assignee: Dmitrii Kriukov
>Priority: Major
> Fix For: 2.2.2
>
>
> I'm going to create one PR per module of the project.
> The first one is https://github.com/apache/tika/pull/478



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3649) Perform findbugs static analysis on the project and address the issues

2022-01-19 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3649:
---
Fix Version/s: 2.2.2

> Perform findbugs static analysis on the project and address the issues
> --
>
> Key: TIKA-3649
> URL: https://issues.apache.org/jira/browse/TIKA-3649
> Project: Tika
>  Issue Type: Improvement
>Reporter: Dmitrii Kriukov
>Priority: Major
> Fix For: 2.2.2
>
>
> I'm going to create one PR per module of the project.
> The first one is https://github.com/apache/tika/pull/478



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3649) Perform findbugs static analysis on the project and address the issues

2022-01-19 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3649:
---
Summary: Perform findbugs static analysis on the project and address the 
issues  (was: Perform static analysis on the project and address the issues)

> Perform findbugs static analysis on the project and address the issues
> --
>
> Key: TIKA-3649
> URL: https://issues.apache.org/jira/browse/TIKA-3649
> Project: Tika
>  Issue Type: Improvement
>Reporter: Dmitrii Kriukov
>Priority: Major
>
> I'm going to create one PR per module of the project.
> The first one is https://github.com/apache/tika/pull/478



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3651) Activate Dependabot on Tika main branch

2022-01-18 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3651:
--

 Summary: Activate Dependabot on Tika main branch
 Key: TIKA-3651
 URL: https://issues.apache.org/jira/browse/TIKA-3651
 Project: Tika
  Issue Type: Improvement
  Components: depedency, build, security
Affects Versions: 2.2.1
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.2.2


[Dependabot|https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates]
 allows projects to keep the packages you use updated to the latest versions.
It is a piece of cake to configure. PR coming up.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3648) Fail build if ossindex-maven-plugin violation is detected

2022-01-18 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478180#comment-17478180
 ] 

Lewis John McGibbney commented on TIKA-3648:


{quote}dependabot only sends one ping/PR per dependency and we can ignore it 
for those dependencies, right?{quote}

Correct. I will send that in a different PR right now.

> Fail build if ossindex-maven-plugin violation is detected
> -
>
> Key: TIKA-3648
> URL: https://issues.apache.org/jira/browse/TIKA-3648
> Project: Tika
>  Issue Type: Improvement
>  Components: build, security
>Affects Versions: 2.2.1
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Critical
> Fix For: 2.2.2
>
>
> The ossindex-maven-plugin can really assist us in detecting and preventing 
> security vulnerabilities and also mitigating associated risk and exposure.
> I propose to fail the build if ossindex-maven-plugin violation is detected
> https://github.com/apache/tika/blob/main/tika-parent/pom.xml#L639



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3648) Fail build if ossindex-maven-plugin violation is detected

2022-01-18 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478172#comment-17478172
 ] 

Lewis John McGibbney commented on TIKA-3648:


Your points are well made and I hear you. What do you think about turning on 
Dependabot? This way we keep up with issues as we go along. I personally feel 
Tika has more to gain by turning on Dependabot than by not. The dependency 
sprawl is pretty significant across the codebase so anything we can do to keep 
on top of things would be great. 

> Fail build if ossindex-maven-plugin violation is detected
> -
>
> Key: TIKA-3648
> URL: https://issues.apache.org/jira/browse/TIKA-3648
> Project: Tika
>  Issue Type: Improvement
>  Components: build, security
>Affects Versions: 2.2.1
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Critical
> Fix For: 2.2.2
>
>
> The ossindex-maven-plugin can really assist us in detecting and preventing 
> security vulnerabilities and also mitigating associated risk and exposure.
> I propose to fail the build if ossindex-maven-plugin violation is detected
> https://github.com/apache/tika/blob/main/tika-parent/pom.xml#L639



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3648) Fail build if ossindex-maven-plugin violation is detected

2022-01-16 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3648:
--

 Summary: Fail build if ossindex-maven-plugin violation is detected
 Key: TIKA-3648
 URL: https://issues.apache.org/jira/browse/TIKA-3648
 Project: Tika
  Issue Type: Improvement
  Components: security, build
Affects Versions: 2.2.1
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.2.2


The ossindex-maven-plugin can really assist us in detecting and preventing 
security vulnerabilities and also mitigating associated risk and exposure.
I propose to fail the build if ossindex-maven-plugin violation is detected
https://github.com/apache/tika/blob/main/tika-parent/pom.xml#L639



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-3539) jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3539.

Resolution: Fixed

> jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE
> 
>
> Key: TIKA-3539
> URL: https://issues.apache.org/jira/browse/TIKA-3539
> Project: Tika
>  Issue Type: Task
>  Components: parser
>Affects Versions: 2.1.0
>Reporter: Julian Reschke
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Might be good to avoid the use of JDOM altogether.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Assigned] (TIKA-3539) jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney reassigned TIKA-3539:
--

Assignee: Lewis John McGibbney

> jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE
> 
>
> Key: TIKA-3539
> URL: https://issues.apache.org/jira/browse/TIKA-3539
> Project: Tika
>  Issue Type: Task
>  Components: parser
>Affects Versions: 2.1.0
>Reporter: Julian Reschke
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Might be good to avoid the use of JDOM altogether.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3539) jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE

2021-12-29 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466682#comment-17466682
 ] 

Lewis John McGibbney commented on TIKA-3539:


This issue was fixed for 2.X in https://github.com/apache/tika/pull/469

> jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE
> 
>
> Key: TIKA-3539
> URL: https://issues.apache.org/jira/browse/TIKA-3539
> Project: Tika
>  Issue Type: Task
>  Components: parser
>Affects Versions: 2.1.0
>Reporter: Julian Reschke
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Might be good to avoid the use of JDOM altogether.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3539) jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3539:
---
Fix Version/s: 2.2.1

> jdom 2.0.6 dependency in tika-parser-news-module has unfixed CVE
> 
>
> Key: TIKA-3539
> URL: https://issues.apache.org/jira/browse/TIKA-3539
> Project: Tika
>  Issue Type: Task
>  Components: parser
>Affects Versions: 2.1.0
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 2.2.1
>
>
> Might be good to avoid the use of JDOM altogether.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-3635) Upgrade to rome 1.18.0

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3635.

Resolution: Fixed

> Upgrade to rome 1.18.0
> --
>
> Key: TIKA-3635
> URL: https://issues.apache.org/jira/browse/TIKA-3635
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 2.2.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> It looks like my activity over on the rome project had a positive impact. 
> Although the project is basically dormant, the primary author took on the 
> task of pulling in my work and improving on it which is excellent. He's made 
> two releases in the last week or so.
> (Hopefully) a trivial dependency upgrade PR coming up... 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-3488) Security issue XXE in TIKA due to JDOM

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3488.

Resolution: Fixed

> Security issue XXE in TIKA due to JDOM
> --
>
> Key: TIKA-3488
> URL: https://issues.apache.org/jira/browse/TIKA-3488
> Project: Tika
>  Issue Type: Task
>  Components: tika-server
>Affects Versions: 1.25
>Reporter: Arvind Jagtap
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Apache TIKA 1.35 is vulnerable due to dependency on JDOM 2.0.6. Black Duck 
> Hub has reported this vulnerability CVE-2021-33813 with more detail on the 
> following page. 
> [https://nvd.nist.gov/vuln/detail/CVE-2021-33813#range-6782705]
> Although the following issue is entered, it is not yet fixed and there is no 
> timeline given.
> https://github.com/hunterhacker/jdom/issues/189
> There are some workaround discussed on this issue. Can this be fixed in TIKA 
> in the meanwhile?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3488) Security issue XXE in TIKA due to JDOM

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3488:
---
Fix Version/s: 2.2.1

> Security issue XXE in TIKA due to JDOM
> --
>
> Key: TIKA-3488
> URL: https://issues.apache.org/jira/browse/TIKA-3488
> Project: Tika
>  Issue Type: Task
>  Components: tika-server
>Affects Versions: 1.25
>Reporter: Arvind Jagtap
>Priority: Major
> Fix For: 2.2.1
>
>
> Apache TIKA 1.35 is vulnerable due to dependency on JDOM 2.0.6. Black Duck 
> Hub has reported this vulnerability CVE-2021-33813 with more detail on the 
> following page. 
> [https://nvd.nist.gov/vuln/detail/CVE-2021-33813#range-6782705]
> Although the following issue is entered, it is not yet fixed and there is no 
> timeline given.
> https://github.com/hunterhacker/jdom/issues/189
> There are some workaround discussed on this issue. Can this be fixed in TIKA 
> in the meanwhile?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Assigned] (TIKA-3488) Security issue XXE in TIKA due to JDOM

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney reassigned TIKA-3488:
--

Assignee: Lewis John McGibbney

> Security issue XXE in TIKA due to JDOM
> --
>
> Key: TIKA-3488
> URL: https://issues.apache.org/jira/browse/TIKA-3488
> Project: Tika
>  Issue Type: Task
>  Components: tika-server
>Affects Versions: 1.25
>Reporter: Arvind Jagtap
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Apache TIKA 1.35 is vulnerable due to dependency on JDOM 2.0.6. Black Duck 
> Hub has reported this vulnerability CVE-2021-33813 with more detail on the 
> following page. 
> [https://nvd.nist.gov/vuln/detail/CVE-2021-33813#range-6782705]
> Although the following issue is entered, it is not yet fixed and there is no 
> timeline given.
> https://github.com/hunterhacker/jdom/issues/189
> There are some workaround discussed on this issue. Can this be fixed in TIKA 
> in the meanwhile?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3488) Security issue XXE in TIKA due to JDOM

2021-12-29 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466681#comment-17466681
 ] 

Lewis John McGibbney commented on TIKA-3488:


This was fixed in https://github.com/apache/tika/pull/469

> Security issue XXE in TIKA due to JDOM
> --
>
> Key: TIKA-3488
> URL: https://issues.apache.org/jira/browse/TIKA-3488
> Project: Tika
>  Issue Type: Task
>  Components: tika-server
>Affects Versions: 1.25
>Reporter: Arvind Jagtap
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> Apache TIKA 1.35 is vulnerable due to dependency on JDOM 2.0.6. Black Duck 
> Hub has reported this vulnerability CVE-2021-33813 with more detail on the 
> following page. 
> [https://nvd.nist.gov/vuln/detail/CVE-2021-33813#range-6782705]
> Although the following issue is entered, it is not yet fixed and there is no 
> timeline given.
> https://github.com/hunterhacker/jdom/issues/189
> There are some workaround discussed on this issue. Can this be fixed in TIKA 
> in the meanwhile?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3635) Upgrade to rome 1.18.0

2021-12-29 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3635:
---
Fix Version/s: 2.2.1

> Upgrade to rome 1.18.0
> --
>
> Key: TIKA-3635
> URL: https://issues.apache.org/jira/browse/TIKA-3635
> Project: Tika
>  Issue Type: Improvement
>  Components: parser
>Affects Versions: 2.2.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.1
>
>
> It looks like my activity over on the rome project had a positive impact. 
> Although the project is basically dormant, the primary author took on the 
> task of pulling in my work and improving on it which is excellent. He's made 
> two releases in the last week or so.
> (Hopefully) a trivial dependency upgrade PR coming up... 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3635) Upgrade to rome 1.18.0

2021-12-29 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3635:
--

 Summary: Upgrade to rome 1.18.0
 Key: TIKA-3635
 URL: https://issues.apache.org/jira/browse/TIKA-3635
 Project: Tika
  Issue Type: Improvement
  Components: parser
Affects Versions: 2.2.0
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney


It looks like my activity over on the rome project had a positive impact. 
Although the project is basically dormant, the primary author took on the task 
of pulling in my work and improving on it which is excellent. He's made two 
releases in the last week or so.
(Hopefully) a trivial dependency upgrade PR coming up... 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


Re: 2.2.0 JARs not pushed to Maven Central

2021-12-17 Thread Lewis John McGibbney
Thanks Dave.
I saw https://issues.apache.org/jira/browse/INFRA-22626
Looks like Tika was suffering from the same issue.
The jar's are now available.
Thanks

On 2021/12/17 23:06:26 Dave Fisher wrote:
> Get on #afinfra in slack and look at the scroll back.
> 
> > On Dec 17, 2021, at 2:59 PM, lewis john mcgibbney  
> > wrote:
> > 
> > I’ve been waiting on the M2 central Repository being updated with the 2.2.0
> > jars…
> > I checked repository.Apache.org and they are NOT staged which I assume
> > means that the staging repository has been closed which should have
> > triggered the release to maven central.
> > Anyone know what’s going on?
> > lewismc
> > -- 
> > http://home.apache.org/~lewismc/
> > http://people.apache.org/keys/committer/lewismc
> 
> 


2.2.0 JARs not pushed to Maven Central

2021-12-17 Thread lewis john mcgibbney
I’ve been waiting on the M2 central Repository being updated with the 2.2.0
jars…
I checked repository.Apache.org and they are NOT staged which I assume
means that the staging repository has been closed which should have
triggered the release to maven central.
Anyone know what’s going on?
lewismc
-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


[jira] [Updated] (TIKA-3620) Language detection documentation needs attention

2021-12-17 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3620:
---
Fix Version/s: 2.2.0

> Language detection documentation needs attention
> 
>
> Key: TIKA-3620
> URL: https://issues.apache.org/jira/browse/TIKA-3620
> Project: Tika
>  Issue Type: Improvement
>  Components: languageidentifier
>Affects Versions: 2.1.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.0
>
>
> This language identifier/detection suffers from a few problems
> # Clarity is needed on identifier/identification Vs detector/detection. Which 
> is it? The source code says identifier whereas the [documentation is nested 
> under 
> detection|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
> # The 
> [org.apache.tika.language.LanguageIdentifier|https://tika.apache.org/2.1.0/api/org/apache/tika/language/LanguageIdentifier.html]
>  returns 404. What is this meant to resolve to?
> # Generally speaking the [documentation is literally 
> non-existent|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
>  I checked the wiki and failed to find anything. I did find some [minor 
> documentation|https://tika.apache.org/2.1.0/examples.html#Language_Identification]
>  but this is also severely lacking. Also note the broken hyperlink.
> Some suggestions for improvement
> # Fix the broken hyperlinks.
> # Hyperlink to the existing example namely 
> [LanguageDetectorExample.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectorExample.java],
>  
> [LanguageDetectingParser.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectingParser.java]
>  and 
> [Language.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/Language.java]
> # Hyperlink to the [LanguageDetector 
> Javadoc|https://tika.apache.org/2.1.0/api/index.html?org/apache/tika/language/detect/LanguageDetector.html]
>  and atleast mention some of the other implementations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-3620) Language detection documentation needs attention

2021-12-17 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3620.

Resolution: Fixed

https://tika.apache.org/2.2.0/detection.html#Language_Detection

> Language detection documentation needs attention
> 
>
> Key: TIKA-3620
> URL: https://issues.apache.org/jira/browse/TIKA-3620
> Project: Tika
>  Issue Type: Improvement
>  Components: languageidentifier
>Affects Versions: 2.1.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.2.0
>
>
> This language identifier/detection suffers from a few problems
> # Clarity is needed on identifier/identification Vs detector/detection. Which 
> is it? The source code says identifier whereas the [documentation is nested 
> under 
> detection|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
> # The 
> [org.apache.tika.language.LanguageIdentifier|https://tika.apache.org/2.1.0/api/org/apache/tika/language/LanguageIdentifier.html]
>  returns 404. What is this meant to resolve to?
> # Generally speaking the [documentation is literally 
> non-existent|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
>  I checked the wiki and failed to find anything. I did find some [minor 
> documentation|https://tika.apache.org/2.1.0/examples.html#Language_Identification]
>  but this is also severely lacking. Also note the broken hyperlink.
> Some suggestions for improvement
> # Fix the broken hyperlinks.
> # Hyperlink to the existing example namely 
> [LanguageDetectorExample.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectorExample.java],
>  
> [LanguageDetectingParser.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectingParser.java]
>  and 
> [Language.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/Language.java]
> # Hyperlink to the [LanguageDetector 
> Javadoc|https://tika.apache.org/2.1.0/api/index.html?org/apache/tika/language/detect/LanguageDetector.html]
>  and atleast mention some of the other implementations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3620) Language detection documentation needs attention

2021-12-17 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461618#comment-17461618
 ] 

Lewis John McGibbney commented on TIKA-3620:


% svn ci -m "TIKA-3620 Language detection documentation needs attention"
Sendingpublish/2.2.0/detection.html
Sendingsrc/site/apt/2.2.0/detection.apt
Transmitting file data ..done
Committing transaction...
Committed revision 1896103.

> Language detection documentation needs attention
> 
>
> Key: TIKA-3620
> URL: https://issues.apache.org/jira/browse/TIKA-3620
> Project: Tika
>  Issue Type: Improvement
>  Components: languageidentifier
>Affects Versions: 2.1.0
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
>
> This language identifier/detection suffers from a few problems
> # Clarity is needed on identifier/identification Vs detector/detection. Which 
> is it? The source code says identifier whereas the [documentation is nested 
> under 
> detection|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
> # The 
> [org.apache.tika.language.LanguageIdentifier|https://tika.apache.org/2.1.0/api/org/apache/tika/language/LanguageIdentifier.html]
>  returns 404. What is this meant to resolve to?
> # Generally speaking the [documentation is literally 
> non-existent|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
>  I checked the wiki and failed to find anything. I did find some [minor 
> documentation|https://tika.apache.org/2.1.0/examples.html#Language_Identification]
>  but this is also severely lacking. Also note the broken hyperlink.
> Some suggestions for improvement
> # Fix the broken hyperlinks.
> # Hyperlink to the existing example namely 
> [LanguageDetectorExample.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectorExample.java],
>  
> [LanguageDetectingParser.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectingParser.java]
>  and 
> [Language.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/Language.java]
> # Hyperlink to the [LanguageDetector 
> Javadoc|https://tika.apache.org/2.1.0/api/index.html?org/apache/tika/language/detect/LanguageDetector.html]
>  and atleast mention some of the other implementations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3616) Upgrade log4j2

2021-12-16 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460813#comment-17460813
 ] 

Lewis John McGibbney commented on TIKA-3616:


Hi Tim,
I’m not familiar with the downstream release process for the various Docker
artifacts.
Publishing the Helm chart is a walk in the park but entirely conditional
upon the Docker artifact.
Here’s the release process

https://wiki.apache.org/confluence/display/TIKA/Release+Process+for+tika-helm

Can I make the helm release? Absolutely.


-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc


> Upgrade log4j2
> --
>
> Key: TIKA-3616
> URL: https://issues.apache.org/jira/browse/TIKA-3616
> Project: Tika
>  Issue Type: Task
>Reporter: Tim Allison
>Priority: Major
> Fix For: 2.1.1
>
>
> RCE...might be difficult to trigger in Tika, but why ask for a PoC...
> This only affects 2.x.  We were still using the old log4j in 1.x



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3620) Language detection documentation needs attention

2021-12-15 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3620:
--

 Summary: Language detection documentation needs attention
 Key: TIKA-3620
 URL: https://issues.apache.org/jira/browse/TIKA-3620
 Project: Tika
  Issue Type: Improvement
  Components: languageidentifier
Affects Versions: 2.1.0
Reporter: Lewis John McGibbney


This language identifier/detection suffers from a few problems
# Clarity is needed on identifier/identification Vs detector/detection. Which 
is it? The source code says identifier whereas the [documentation is nested 
under 
detection|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
# The 
[org.apache.tika.language.LanguageIdentifier|https://tika.apache.org/2.1.0/api/org/apache/tika/language/LanguageIdentifier.html]
 returns 404. What is this meant to resolve to?
# Generally speaking the [documentation is literally 
non-existent|https://tika.apache.org/2.1.0/detection.html#Language_Detection]. 
I checked the wiki and failed to find anything. I did find some [minor 
documentation|https://tika.apache.org/2.1.0/examples.html#Language_Identification]
 but this is also severely lacking. Also note the broken hyperlink.

Some suggestions for improvement
# Fix the broken hyperlinks.
# Hyperlink to the existing example namely 
[LanguageDetectorExample.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectorExample.java],
 
[LanguageDetectingParser.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectingParser.java]
 and 
[Language.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/Language.java]
# Hyperlink to the [LanguageDetector 
Javadoc|https://tika.apache.org/2.1.0/api/index.html?org/apache/tika/language/detect/LanguageDetector.html]
 and atleast mention some of the other implementations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Assigned] (TIKA-3620) Language detection documentation needs attention

2021-12-15 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney reassigned TIKA-3620:
--

Assignee: Lewis John McGibbney

> Language detection documentation needs attention
> 
>
> Key: TIKA-3620
> URL: https://issues.apache.org/jira/browse/TIKA-3620
> Project: Tika
>  Issue Type: Improvement
>  Components: languageidentifier
>Affects Versions: 2.1.0
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
>
> This language identifier/detection suffers from a few problems
> # Clarity is needed on identifier/identification Vs detector/detection. Which 
> is it? The source code says identifier whereas the [documentation is nested 
> under 
> detection|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
> # The 
> [org.apache.tika.language.LanguageIdentifier|https://tika.apache.org/2.1.0/api/org/apache/tika/language/LanguageIdentifier.html]
>  returns 404. What is this meant to resolve to?
> # Generally speaking the [documentation is literally 
> non-existent|https://tika.apache.org/2.1.0/detection.html#Language_Detection].
>  I checked the wiki and failed to find anything. I did find some [minor 
> documentation|https://tika.apache.org/2.1.0/examples.html#Language_Identification]
>  but this is also severely lacking. Also note the broken hyperlink.
> Some suggestions for improvement
> # Fix the broken hyperlinks.
> # Hyperlink to the existing example namely 
> [LanguageDetectorExample.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectorExample.java],
>  
> [LanguageDetectingParser.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/LanguageDetectingParser.java]
>  and 
> [Language.java|https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/Language.java]
> # Hyperlink to the [LanguageDetector 
> Javadoc|https://tika.apache.org/2.1.0/api/index.html?org/apache/tika/language/detect/LanguageDetector.html]
>  and atleast mention some of the other implementations.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3241) Clarify parser module structure in 2.0.0

2021-12-15 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460066#comment-17460066
 ] 

Lewis John McGibbney commented on TIKA-3241:


Hi [~tallison] can this ticket be closed?

> Clarify parser module structure in 2.0.0
> 
>
> Key: TIKA-3241
> URL: https://issues.apache.org/jira/browse/TIKA-3241
> Project: Tika
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Major
>
> In 2.0.0, we currently have:
> tika-parser-modules/
> tika-parsers/
> tika-parsers-advanced/
> tika-parsers-extended
> where {{tika-parsers}} is a module that includes all parsers in 
> {{tika-parser-modules}}.
> I think we can make the structure a bit clearer by:
> tika-parsers/
>tika-parsers-classic/ (renamed from tika-parser-modules)
>tika-parsers-advanced/
>tika-parsers-extended
> As before in 2.0.0, tika-app and tika-server would pull from 
> tika-parsers-classic.  If users wanted the heavier parsers in 
> tika-parsers-advanced/tika-parsers-extended, they could pull those in on 
> their own.
>   



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (TIKA-3229) mvn clean install failure - tika-1.24 on windows

2021-12-15 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460065#comment-17460065
 ] 

Lewis John McGibbney commented on TIKA-3229:


[~Simmo] are you able to reproduce this/ Otherwise I think we should close this 
ticket. 

> mvn clean install failure -  tika-1.24 on windows
> -
>
> Key: TIKA-3229
> URL: https://issues.apache.org/jira/browse/TIKA-3229
> Project: Tika
>  Issue Type: Bug
>Affects Versions: 1.24
> Environment: windows 10
>Reporter: Simon Opper
>Priority: Major
>
> getting a build fail on mvn clean install
>  
> ERROR] Failed to execute goal 
> org.apache.felix:maven-bundle-plugin:4.1.0:bundle (default-bundle) on project 
> tika-core: Execution default-bundle of goal 
> org.apache.felix:maven-bundle-plugin:4.1.0:bundle failed.: 
> ConcurrentModificationException -> [Help 1]
>  
> the complete verbose error text is below
>  
>  --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ tika-core ---
> [INFO] 
> 
> [INFO] Reactor Summary for Apache Tika 2.0.0-SNAPSHOT:
> [INFO]
> [INFO] Apache Tika parent . SUCCESS [  1.813 
> s]
> [INFO] Apache Tika core ... FAILURE [  7.528 
> s]
> [INFO] Apache Tika parser modules . SKIPPED
> [INFO] tika-parser-jdbc-commons ... SKIPPED
> [INFO] tika-parser-digest-commons . SKIPPED
> [INFO] tika-parser-mail-commons ... SKIPPED
> [INFO] tika-parser-xmp-commons  SKIPPED
> [INFO] tika-parser-zip-commons  SKIPPED
> [INFO] tika-parser-image-module ... SKIPPED
> [INFO] tika-parser-ocr-module . SKIPPED
> [INFO] tika-parser-audiovideo-module .. SKIPPED
> [INFO] tika-parser-text-module  SKIPPED
> [INFO] tika-parser-code-module  SKIPPED
> [INFO] tika-parser-html-module  SKIPPED
> [INFO] tika-parser-font-module  SKIPPED
> [INFO] tika-parser-xml-module . SKIPPED
> [INFO] tika-parser-microsoft-module ... SKIPPED
> [INFO] tika-parser-pkg-module . SKIPPED
> [INFO] tika-parser-pdf-module . SKIPPED
> [INFO] tika-parser-apple-module ... SKIPPED
> [INFO] tika-parser-cad-module . SKIPPED
> [INFO] tika-parser-mail-module  SKIPPED
> [INFO] tika-parser-miscoffice-module .. SKIPPED
> [INFO] tika-parser-news-module  SKIPPED
> [INFO] tika-parser-crypto-module .. SKIPPED
> [INFO] tika-parser-integration-tests .. SKIPPED
> [INFO] tika-parsers ... SKIPPED
> [INFO] tika-parsers-extended .. SKIPPED
> [INFO] tika-parser-sqlite3-module . SKIPPED
> [INFO] tika-parser-scientific-module .. SKIPPED
> [INFO] tika-parsers-extended-integration-tests  SKIPPED
> [INFO] Apache Tika XMP  SKIPPED
> [INFO] Apache Tika serialization .. SKIPPED
> [INFO] Apache Tika batch .. SKIPPED
> [INFO] Apache Tika language detection . SKIPPED
> [INFO] tika-langdetect-commons  SKIPPED
> [INFO] tika-langdetect-lingo24  SKIPPED
> [INFO] tika-langdetect-optimaize .. SKIPPED
> [INFO] tika-langdetect-mitll-text . SKIPPED
> [INFO] tika-langdetect-opennlp  SKIPPED
> [INFO] Apache Tika application  SKIPPED
> [INFO] Apache Tika translate .. SKIPPED
> [INFO] Apache Tika server . SKIPPED
> [INFO] Apache Tika fuzzing  SKIPPED
> [INFO] Apache Tika eval ... SKIPPED
> [INFO] Apache Tika examples ... SKIPPED
> [INFO] Apache Tika Java-7 Components .. SKIPPED
> [INFO] tika-parsers-advanced .. SKIPPED
> [INFO] tika-parser-nlp-module ..

[jira] [Resolved] (TIKA-491) Add language identification support for Norwegian Bokmål and Norwegian Nynorsk

2021-12-15 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-491.
---
Resolution: Won't Fix

Cleanup [~kkrugler] [~pandermusubi]

> Add language identification support for Norwegian Bokmål and Norwegian Nynorsk
> --
>
> Key: TIKA-491
> URL: https://issues.apache.org/jira/browse/TIKA-491
> Project: Tika
>  Issue Type: New Feature
>  Components: languageidentifier
>Affects Versions: 0.7
>Reporter: Jan Høydahl
>Assignee: Kenneth William Krugler
>Priority: Major
>
> Currently there is one Norwegian language profile in Tika - "no". We need to 
> distinguish between the two official Norwegian languages defined by ISO 639-1 
> codes "nb" and "nn". Those codes are recommended used instead of the common 
> "no" tag.
> Proposed solved by removing the current language profile no.ngp and replacing 
> it with two new ones for nb and nn.
> We must also add tests for Norwegian



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-369) Improve accuracy of language detection

2021-12-15 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-369.
---
Resolution: Fixed

Cleaning this one up [~kkrugler]

> Improve accuracy of language detection
> --
>
> Key: TIKA-369
> URL: https://issues.apache.org/jira/browse/TIKA-369
> Project: Tika
>  Issue Type: Improvement
>  Components: languageidentifier
>Affects Versions: 0.6
>Reporter: Kenneth William Krugler
>Assignee: Kenneth William Krugler
>Priority: Major
> Attachments: Surprise and Coincidence.pdf, lingdet-mccs.pdf, 
> textcat.pdf
>
>
> Currently the LanguageProfile code uses 3-grams to find the best language 
> profile using Pearson's chi-square test. This has three issues:
> 1. The results aren't very good for short runs of text. Ted Dunning's paper 
> (attached) indicates that a log-likelihood ratio (LLR) test works much 
> better, which would then make language detection faster due to less text 
> needing to be processed.
> 2. The current LanguageIdentifier.isReasonablyCertain() method uses an exact 
> value as a threshold for certainty. This is very sensitive to the amount of 
> text being processed, and thus gives false negative results for short runs of 
> text.
> 3. Certainty should also be based on how much better the result is for 
> language X, compared to the next best language. If two languages both had 
> identical sum-of-squares values, and this value was below the threshold, then 
> the result is still not very certain.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3619) Augment README with build prerequisites

2021-12-14 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3619:
--

 Summary: Augment README with build prerequisites
 Key: TIKA-3619
 URL: https://issues.apache.org/jira/browse/TIKA-3619
 Project: Tika
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.2.0
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney


When [reviewing the 2.2.0 RC 
|https://lists.apache.org/thread/pfwm8sn7w3lsrsckd8b9v3b32byj4zms] I became 
aware that although Docker IS required to build tika-pipes modules, there is no 
guidance to reflect that.
I think we could cleanup the README to reflect the installation prerequisites.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


Re: [VOTE] Release Apache Tika 2.2.0 Candidate #1

2021-12-14 Thread Lewis John McGibbney
I'll submit a PR for the README but I think it's also worthwile to augment the 
release management guide so that the message to review the release candidate 
includes this information.
lewismc

On 2021/12/14 20:17:05 Tim Allison wrote:
> Y, you're right. Lewis, where should we mention the Docker requirement
> on our site?
> 
> On Tue, Dec 14, 2021 at 3:06 PM Lewis John McGibbney  
> wrote:
> >
> > Hi Ken,
> >
> > On 2021/12/13 22:38:49 Ken Krugler wrote:
> > > That error looks like you’ve got a connection issue with the Maven 
> > > central repo…
> > >
> > > — Ken
> >
> > Yes you are correct :)
> >
> > Once that issue sorted itself out my local build passed so my +1 stands.
> >
> > I this it is worthwhile us stating that Docker is a prerequisite for 
> > installing from source. This is required for the tika-pipes* modules.
> >
> > lewismc
> 


Re: [VOTE] Release Apache Tika 2.2.0 Candidate #1

2021-12-14 Thread Lewis John McGibbney
Hi Ken,

On 2021/12/13 22:38:49 Ken Krugler wrote:
> That error looks like you’ve got a connection issue with the Maven central 
> repo…
> 
> — Ken

Yes you are correct :)

Once that issue sorted itself out my local build passed so my +1 stands.

I this it is worthwhile us stating that Docker is a prerequisite for installing 
from source. This is required for the tika-pipes* modules.

lewismc


Re: [VOTE] Release Apache Tika 2.2.0 Candidate #1

2021-12-13 Thread Lewis John McGibbney
I performed another build of the tika-2.2.0-src.zip artifact which failed. I've 
captured the failure output

https://paste.apache.org/o9iju

% mvn -version
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 11.0.10, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk-11.0.10.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.7", arch: "x86_64", family: "mac"

Can anyone else reproduce this failure?

lewismc

On 2021/12/13 22:13:41 Lewis John McGibbney wrote:
> Hi Tim,
> 
> On 2021/12/13 21:37:47 Tim Allison wrote:
> > A candidate for the Tika 2.2.0 release is available at:
> > https://dist.apache.org/repos/dist/dev/tika/
> 
> I downloaded the tika-2.2.0-src.zip artifact
> > 9083fa1973f7146d2869bbdfa2dbdd493e12ac04235b9a4017a01b0b475684a2bc4377149a5a36b68722525fa3de68c7e06b2f7095af0c1e9f8510fba23e2b8d.
> 
> .sha512 signature good
> .asc signature is good
> pom.xml versions all match
> good NOTICE.txt
> good CHANGES.txt
> 
> > 
> > In addition, a staged maven repository is available here:
> > https://repository.apache.org/content/repositories/orgapachetika-1073/org/apache/tika
> > 
> 
> I added the following to Any23 master pom.xml and ran our unit test suite
> 
> 
>   
> apache-repo-snapshots
> https://repository.apache.org/content/repositories/snapshots/
> 
>   false
> 
> 
>   true
> 
>   
> 
> 
> Everything passes successfully.
> 
> > 
> > [X] +1 Release this package as Apache Tika 2.2.0
> 
> I did notice that the tika DL's module(s) are pulling in the enire Hadoop 
> dependency chain. I wonder if we can cut down on this... that is however a 
> concern outside of this release candidate review.
> 
> Thanks for the quick turnaround.
> lewismc
> 


Re: [VOTE] Release Apache Tika 2.2.0 Candidate #1

2021-12-13 Thread Lewis John McGibbney
I forgot to mention. I performed a full clean install on the tika-2.2.0-src.zip 
artifact and everything installed and tested successfully.

On 2021/12/13 22:13:41 Lewis John McGibbney wrote:
> Hi Tim,
> 
> On 2021/12/13 21:37:47 Tim Allison wrote:
> > A candidate for the Tika 2.2.0 release is available at:
> > https://dist.apache.org/repos/dist/dev/tika/
> 
> I downloaded the tika-2.2.0-src.zip artifact
> > 9083fa1973f7146d2869bbdfa2dbdd493e12ac04235b9a4017a01b0b475684a2bc4377149a5a36b68722525fa3de68c7e06b2f7095af0c1e9f8510fba23e2b8d.
> 
> .sha512 signature good
> .asc signature is good
> pom.xml versions all match
> good NOTICE.txt
> good CHANGES.txt
> 
> > 
> > In addition, a staged maven repository is available here:
> > https://repository.apache.org/content/repositories/orgapachetika-1073/org/apache/tika
> > 
> 
> I added the following to Any23 master pom.xml and ran our unit test suite
> 
> 
>   
> apache-repo-snapshots
> https://repository.apache.org/content/repositories/snapshots/
> 
>   false
> 
> 
>   true
> 
>   
> 
> 
> Everything passes successfully.
> 
> > 
> > [X] +1 Release this package as Apache Tika 2.2.0
> 
> I did notice that the tika DL's module(s) are pulling in the enire Hadoop 
> dependency chain. I wonder if we can cut down on this... that is however a 
> concern outside of this release candidate review.
> 
> Thanks for the quick turnaround.
> lewismc
> 


Re: [VOTE] Release Apache Tika 2.2.0 Candidate #1

2021-12-13 Thread Lewis John McGibbney
Hi Tim,

On 2021/12/13 21:37:47 Tim Allison wrote:
> A candidate for the Tika 2.2.0 release is available at:
> https://dist.apache.org/repos/dist/dev/tika/

I downloaded the tika-2.2.0-src.zip artifact
> 9083fa1973f7146d2869bbdfa2dbdd493e12ac04235b9a4017a01b0b475684a2bc4377149a5a36b68722525fa3de68c7e06b2f7095af0c1e9f8510fba23e2b8d.

.sha512 signature good
.asc signature is good
pom.xml versions all match
good NOTICE.txt
good CHANGES.txt

> 
> In addition, a staged maven repository is available here:
> https://repository.apache.org/content/repositories/orgapachetika-1073/org/apache/tika
> 

I added the following to Any23 master pom.xml and ran our unit test suite


  
apache-repo-snapshots
https://repository.apache.org/content/repositories/snapshots/

  false


  true

  


Everything passes successfully.

> 
> [X] +1 Release this package as Apache Tika 2.2.0

I did notice that the tika DL's module(s) are pulling in the enire Hadoop 
dependency chain. I wonder if we can cut down on this... that is however a 
concern outside of this release candidate review.

Thanks for the quick turnaround.
lewismc


[jira] [Commented] (TIKA-3606) Introduce a text summarization capability

2021-12-01 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452086#comment-17452086
 ] 

Lewis John McGibbney commented on TIKA-3606:


I'll most likely compile any needs/wants/suggestions into a wiki page or some 
sort of formal documentation. I'll let this one stew for a bit.

> Introduce a text summarization capability
> -
>
> Key: TIKA-3606
> URL: https://issues.apache.org/jira/browse/TIKA-3606
> Project: Tika
>  Issue Type: New Feature
>  Components: summarization
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
>
> I've been looking out for a nice text summarization capability for a while 
> and have been using [SummerTime|https://github.com/Yale-LILY/SummerTime] 
> recently which is really quite nice.
> From the research I've been doing, the best of class in the summarization 
> field appears to reside within the Python ecosystem. This statement 
> accommodates both summarization results AND usability of the tools.
> Before I go and start writing a tika.summarize API, I wanted to poll the 
> developer community to see what kind of things people are aware of. So here 
> it is, 
> *When thinking about a Tika text summarization capability, what would you 
> like to see?*
> Thanks folks. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Created] (TIKA-3606) Introduce a text summarization capability

2021-12-01 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3606:
--

 Summary: Introduce a text summarization capability
 Key: TIKA-3606
 URL: https://issues.apache.org/jira/browse/TIKA-3606
 Project: Tika
  Issue Type: New Feature
  Components: summarization
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney


I've been looking out for a nice text summarization capability for a while and 
have been using [SummerTime|https://github.com/Yale-LILY/SummerTime] recently 
which is really quite nice.
>From the research I've been doing, the best of class in the summarization 
>field appears to reside within the Python ecosystem. This statement 
>accommodates both summarization results AND usability of the tools.
Before I go and start writing a tika.summarize API, I wanted to poll the 
developer community to see what kind of things people are aware of. So here it 
is, 

*When thinking about a Tika text summarization capability, what would you like 
to see?*

Thanks folks. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Resolved] (TIKA-2796) Update GoogleTranslator to use google-cloud-translate Java API

2021-11-28 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-2796.

Resolution: Duplicate

https://issues.apache.org/jira/browse/TIKA-3404

> Update GoogleTranslator to use google-cloud-translate Java API
> --
>
> Key: TIKA-2796
> URL: https://issues.apache.org/jira/browse/TIKA-2796
> Project: Tika
>  Issue Type: Improvement
>  Components: translation
>Affects Versions: 1.19.1
>    Reporter: Lewis John McGibbney
>    Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.0.0-BETA
>
>
> The GoogleTranslator logic has been neglected and is no longer functional.
> We can upgrade to use the official Google Java API at 
> https://search.maven.org/artifact/com.google.cloud/google-cloud-translate/1.54.0/jar
> Additionally, documentaion for this upgrade can be found at 
> https://cloud.google.com/translate/docs/quickstart-client-libraries#client-libraries-install-java



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Updated] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA and 2.1.0

2021-10-08 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3453:
---
Summary: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" 
Defaulting to no-operation (NOP) logger implementation for tika-docker 
2.0.0-BETA and 2.1.0  (was: SLF4J: Failed to load class 
"org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger 
implementation for tika-docker 2.0.0-BETA)

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA and 2.1.0
> ---
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>      Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426383#comment-17426383
 ] 

Lewis John McGibbney commented on TIKA-3453:


The problem lies in the *__* of the [logging 
dependencies|https://github.com/apache/tika/blob/main/tika-server/tika-server-core/pom.xml#L129-L139].


{code:xml}

  org.apache.logging.log4j
  log4j-core
  ${log4j2.version}
  test


  org.apache.logging.log4j
  log4j-slf4j-impl
  ${log4j2.version}
  test
{code}


> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>  Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426378#comment-17426378
 ] 

Lewis John McGibbney commented on TIKA-3453:


OK so the problem lies in the tika-server source NOT with tika-docker or 
tika-helm. Using main branch I can replicate as well

% java -jar tika-server-core-2.1.1-SNAPSHOT.jar
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
Oct 08, 2021 2:05:20 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://localhost:9998/

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>      Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426372#comment-17426372
 ] 

Lewis John McGibbney commented on TIKA-3453:


[~davemeikle] can you also reproduce?

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>  Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426369#comment-17426369
 ] 

Lewis John McGibbney edited comment on TIKA-3453 at 10/8/21, 8:47 PM:
--

Yep I can reproduce this [~scottbessler]. Using tika-docker 2.1.0-full via 
tika-helm

{code:bash}
% kubectl logs tika-66796c96-psl2b -n tika -f
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
{code}

[~tallison] was this not supposed to be sorted out? What digging did we do 
before on this?
 Oct 08, 2021 8:40:28 PM org.apache.cxf.endpoint.ServerImpl initDestination
 INFO: Setting the server's publish address to be [http://0.0.0.0:9998/]


was (Author: lewismc):
Yep I can reproduce this [~scottbessler]. Using tika-docker 2.1.0-full via 
tika-helm

{{% kubectl logs tika-66796c96-psl2b -n tika -f
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.}}

[~tallison] was this not supposed to be sorted out? What digging did we do 
before on this?
Oct 08, 2021 8:40:28 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://0.0.0.0:9998/

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>      Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426369#comment-17426369
 ] 

Lewis John McGibbney edited comment on TIKA-3453 at 10/8/21, 8:46 PM:
--

Yep I can reproduce this [~scottbessler]. Using tika-docker 2.1.0-full via 
tika-helm

{{% kubectl logs tika-66796c96-psl2b -n tika -f
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.}}

[~tallison] was this not supposed to be sorted out? What digging did we do 
before on this?
Oct 08, 2021 8:40:28 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://0.0.0.0:9998/


was (Author: lewismc):
Yep I can reproduce this [~scottbessler]. Using tika-docker 2.1.0-full via 
tika-helm
{{% kubectl logs tika-66796c96-psl2b -n tika -f
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.}}

[~tallison] was this not supposed to be sorted out? What digging did we do 
before on this?
Oct 08, 2021 8:40:28 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://0.0.0.0:9998/

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>      Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426369#comment-17426369
 ] 

Lewis John McGibbney commented on TIKA-3453:


Yep I can reproduce this [~scottbessler]. Using tika-docker 2.1.0-full via 
tika-helm
{{% kubectl logs tika-66796c96-psl2b -n tika -f
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.}}

[~tallison] was this not supposed to be sorted out? What digging did we do 
before on this?
Oct 08, 2021 8:40:28 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://0.0.0.0:9998/

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>      Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-08 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3453:
---
Fix Version/s: (was: 2.0.0)
   2.1.1

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>  Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.1.1
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (TIKA-3566) Upgrade tika-helm to 2.1.0

2021-10-08 Thread Lewis John McGibbney (Jira)
Lewis John McGibbney created TIKA-3566:
--

 Summary: Upgrade tika-helm to 2.1.0
 Key: TIKA-3566
 URL: https://issues.apache.org/jira/browse/TIKA-3566
 Project: Tika
  Issue Type: Improvement
  Components: helm
Reporter: Lewis John McGibbney
Assignee: Lewis John McGibbney
 Fix For: 2.1.0


Simple upgrade to [tika-docker 
2.1.0|https://hub.docker.com/layers/apache/tika/2.1.0/images/sha256-5bb52afa9726cf2ca022441cc75ef357de9f8deb41a88a9b2964780e934d11e7?context=explore].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (TIKA-3453) SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA

2021-10-07 Thread Lewis John McGibbney (Jira)


[ 
https://issues.apache.org/jira/browse/TIKA-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425772#comment-17425772
 ] 

Lewis John McGibbney commented on TIKA-3453:


I can investiagte. Thanks [~scottbessler]we didn't upgrade internally yet but I 
will force that now and report back.

> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder" Defaulting to 
> no-operation (NOP) logger implementation for tika-docker 2.0.0-BETA
> -
>
> Key: TIKA-3453
> URL: https://issues.apache.org/jira/browse/TIKA-3453
> Project: Tika
>  Issue Type: Bug
>  Components: docker, server
>    Reporter: Lewis John McGibbney
>Assignee: Lewis John McGibbney
>Priority: Major
> Fix For: 2.0.0
>
>
> It looks like logging libraries are not being interpreted correctly from Java 
> classpath.
> We need logging turned on so we can intercept anomalies.
> Investigating...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (TIKA-3483) Implement a network policy for Helm Chart

2021-08-11 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney resolved TIKA-3483.

Resolution: Fixed

> Implement a network policy for Helm Chart
> -
>
> Key: TIKA-3483
> URL: https://issues.apache.org/jira/browse/TIKA-3483
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>Priority: Major
> Fix For: 2.0.1
>
>
> See https://github.com/apache/tika-helm/pull/5 for context



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (TIKA-3483) Implement a network policy for Helm Chart

2021-08-11 Thread Lewis John McGibbney (Jira)


 [ 
https://issues.apache.org/jira/browse/TIKA-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lewis John McGibbney updated TIKA-3483:
---
Fix Version/s: (was: 2.0.0-BETA)
   2.0.1

> Implement a network policy for Helm Chart
> -
>
> Key: TIKA-3483
> URL: https://issues.apache.org/jira/browse/TIKA-3483
> Project: Tika
>  Issue Type: Improvement
>  Components: helm
>    Reporter: Lewis John McGibbney
>Priority: Major
> Fix For: 2.0.1
>
>
> See https://github.com/apache/tika-helm/pull/5 for context



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: 2.0.1?

2021-07-28 Thread Lewis John McGibbney
Hi Tim,
In short, yes :0)
A couple of questions

1. I see the 2.0.0-BETA development drive is still open in JIRA - 
https://issues.apache.org/jira/projects/TIKA/versions/12350403 should this be 
cleaned up/released/closed?
2. Same for 1.28? https://issues.apache.org/jira/projects/TIKA/versions/12350455
3. 2.0.1 (https://issues.apache.org/jira/projects/TIKA/versions/12350410) looks 
like there are 11 issues done and 3 in progress. In all honesty, I'm not sure 
that these 3 issues are actually in progress at all.

Look forward to 2.0.1...

Thanks
Lewis

On 2021/07/26 21:02:44, Tim Allison  wrote: 
> All,
>   We've made some important cleanups and updated some vulnerable
> dependencies recently.  Should we aim for August 2 or so to start the
> next release process for 2.0.1 (or 2.1.0?)?
>   Thank you!
> 
> Cheers,
> 
>   Tim
> 


  1   2   3   4   5   >