You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Allison, Timothy B." <ta...@mitre.org> on 2015/02/12 16:04:31 UTC
grib adds ~14 MB to tika-app?
All,
I just noticed that tika-app has gone from ~30MB to ~44MB, ~20k file to ~27k files. 3.5 of those new MB are for README.NLDAS1.pdf and README.NLDAS2.pdf. Can we exclude those in the app and server? Are there other items that we should exclude?
Cheers,
Tim
Re: grib adds ~14 MB to tika-app?
Posted by Vineet G H <vg...@gmail.com>.
Yes, sure let me take a look as well
On Fri, Feb 13, 2015 at 8:50 AM, Mattmann, Chris A (3980) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Weird, thanks Tim, Lewis and I will take a look.
> Vineet, can you also take a look?
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: <Allison>, "Timothy B." <ta...@mitre.org>
> Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
> Date: Friday, February 13, 2015 at 4:20 AM
> To: "dev@tika.apache.org" <de...@tika.apache.org>
> Subject: Re: grib adds ~14 MB to tika-app?
>
> >Thank you, Chris!
> >
> >I'm happy to add the excludes statements for the pdfs, but I'm hoping
> >that someone who really knows the grib parser can offer to look into this
> >to see if there are any other things that we can exclude.
> >
> >The other thing I noticed is that there are now a bunch of grib
> >directories at the top level of the jar file, which makes it a mess to
> >navigate. Basically, this doesn't matter, but is there a way to clean
> >that up?
> >
> >Best,
> >
> > Tim
> >
> >________________________________________
> >From: Mattmann, Chris A (3980) <ch...@jpl.nasa.gov>
> >Sent: Friday, February 13, 2015 2:21 AM
> >To: dev@tika.apache.org
> >Subject: Re: grib adds ~14 MB to tika-app?
> >
> >+1 to removing these resources from tika-server, and not
> >shipping them with the binary build - can we exclude it from
> >both tika-server and tika-parsers?
> >
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >Chris Mattmann, Ph.D.
> >Chief Architect
> >Instrument Software and Science Data Systems Section (398)
> >NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >Office: 168-519, Mailstop: 168-527
> >Email: chris.a.mattmann@nasa.gov
> >WWW: http://sunset.usc.edu/~mattmann/
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >Adjunct Associate Professor, Computer Science Department
> >University of Southern California, Los Angeles, CA 90089 USA
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: <Allison>, "Timothy B." <ta...@mitre.org>
> >Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
> >Date: Thursday, February 12, 2015 at 7:04 AM
> >To: "dev@tika.apache.org" <de...@tika.apache.org>
> >Subject: grib adds ~14 MB to tika-app?
> >
> >>All,
> >> I just noticed that tika-app has gone from ~30MB to ~44MB, ~20k file to
> >>~27k files. 3.5 of those new MB are for README.NLDAS1.pdf and
> >>README.NLDAS2.pdf. Can we exclude those in the app and server? Are
> >>there other items that we should exclude?
> >>
> >>
> >> Cheers,
> >>
> >> Tim
> >
>
>
Re: grib adds ~14 MB to tika-app?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Weird, thanks Tim, Lewis and I will take a look.
Vineet, can you also take a look?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Allison>, "Timothy B." <ta...@mitre.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Friday, February 13, 2015 at 4:20 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: Re: grib adds ~14 MB to tika-app?
>Thank you, Chris!
>
>I'm happy to add the excludes statements for the pdfs, but I'm hoping
>that someone who really knows the grib parser can offer to look into this
>to see if there are any other things that we can exclude.
>
>The other thing I noticed is that there are now a bunch of grib
>directories at the top level of the jar file, which makes it a mess to
>navigate. Basically, this doesn't matter, but is there a way to clean
>that up?
>
>Best,
>
> Tim
>
>________________________________________
>From: Mattmann, Chris A (3980) <ch...@jpl.nasa.gov>
>Sent: Friday, February 13, 2015 2:21 AM
>To: dev@tika.apache.org
>Subject: Re: grib adds ~14 MB to tika-app?
>
>+1 to removing these resources from tika-server, and not
>shipping them with the binary build - can we exclude it from
>both tika-server and tika-parsers?
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Chris Mattmann, Ph.D.
>Chief Architect
>Instrument Software and Science Data Systems Section (398)
>NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>Office: 168-519, Mailstop: 168-527
>Email: chris.a.mattmann@nasa.gov
>WWW: http://sunset.usc.edu/~mattmann/
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Adjunct Associate Professor, Computer Science Department
>University of Southern California, Los Angeles, CA 90089 USA
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
>-----Original Message-----
>From: <Allison>, "Timothy B." <ta...@mitre.org>
>Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
>Date: Thursday, February 12, 2015 at 7:04 AM
>To: "dev@tika.apache.org" <de...@tika.apache.org>
>Subject: grib adds ~14 MB to tika-app?
>
>>All,
>> I just noticed that tika-app has gone from ~30MB to ~44MB, ~20k file to
>>~27k files. 3.5 of those new MB are for README.NLDAS1.pdf and
>>README.NLDAS2.pdf. Can we exclude those in the app and server? Are
>>there other items that we should exclude?
>>
>>
>> Cheers,
>>
>> Tim
>
Re: grib adds ~14 MB to tika-app?
Posted by "Allison, Timothy B." <ta...@mitre.org>.
Thank you, Chris!
I'm happy to add the excludes statements for the pdfs, but I'm hoping that someone who really knows the grib parser can offer to look into this to see if there are any other things that we can exclude.
The other thing I noticed is that there are now a bunch of grib directories at the top level of the jar file, which makes it a mess to navigate. Basically, this doesn't matter, but is there a way to clean that up?
Best,
Tim
________________________________________
From: Mattmann, Chris A (3980) <ch...@jpl.nasa.gov>
Sent: Friday, February 13, 2015 2:21 AM
To: dev@tika.apache.org
Subject: Re: grib adds ~14 MB to tika-app?
+1 to removing these resources from tika-server, and not
shipping them with the binary build - can we exclude it from
both tika-server and tika-parsers?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Allison>, "Timothy B." <ta...@mitre.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Thursday, February 12, 2015 at 7:04 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: grib adds ~14 MB to tika-app?
>All,
> I just noticed that tika-app has gone from ~30MB to ~44MB, ~20k file to
>~27k files. 3.5 of those new MB are for README.NLDAS1.pdf and
>README.NLDAS2.pdf. Can we exclude those in the app and server? Are
>there other items that we should exclude?
>
>
> Cheers,
>
> Tim
RE: Parser that includes LGPL as "provided"?
Posted by Nick Burch <ap...@gagravarr.org>.
On Fri, 13 Feb 2015, Allison, Timothy B. wrote:
> For your suggestion:
>>> (Actually, there's nothing stopping someone publishing an "all Tika
>>> including LGPL" or "all Tika including GPL" pom, which auto-includes
>>> these for those users who can use things under those licenses in their
>>> projects, but for policy reasons it couldn't be a PMC action to publish
>>> that)
>
> It would be more than just the pom, though. It would have to be a
> separate project that included the Tika parsers that wrapped these
> non-ASL libraries, or do I misunderstand? Oh, wait, are you suggesting:
>
> Step 1) create the Tika wrapper parser as a standalone project, Step 2)
> publish the L?GPL poms to include both the Tika parsers and their
> dependencies?
I'd see it as two steps:
1) Ensure that all the parsers on the 3rd party page have a suitable
published pom, including their dependencies
2) Create new projects (on github etc) as "tika-parser-with-lgpl" and
"tika-parsers-with-lgpl-gpl", which are a pom that depends on
"tika-pasers" and all the gpl and/or lgpl parsers, and a simple unit
test which ensures those parsers were registered + work
Step #2 looks pretty easy, step #1 might be more work as we'd have to get
those parsers released, get their dependencies into maven central etc.
With that work done though, someone who was willing+able to use LGPL
plugins would switch their maven dependency from "org.apache.tika" +
"tika-parsers" to "net.github.tika-extras" + "tika-parsers-with-lgpl"
Since we don't need to offer downloads, just code, Apache Extras might be
possible for hosting the wrapper-pom + unit tests, but it might be that
github would be simpler
If we do want to do this, and if someone's willing to do the work, it
might be best to double-check with legal-discuss to make sure we haven't
missed anything first!
Nick
Re: Parser that includes LGPL as "provided"?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Yep I was part of that discussion :-) That’s my take too - just
don’t :)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Allison>, "Timothy B." <ta...@mitre.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Friday, February 13, 2015 at 5:20 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: RE: Parser that includes LGPL as "provided"?
>Thank you, Nick.
>
>One answer to ("Will the majority of users want to use my product
>without adding the optional components?") [1] would be "No, all users are
>currently using Tika without this optional component. It is just another
>parser that some might want to use for one file type among many."
>
>However, my takeaway from this discussion on [2], [3] is: don't. Just,
>don't. Really, don't.
>
>For your suggestion:
>>>(Actually, there's nothing stopping someone publishing an "all Tika
>>>including LGPL" or "all Tika including GPL" pom, which auto-includes
>>>these for those users who can use things under those licenses in their
>>>projects, but for policy reasons it couldn't be a PMC action to publish
>>>that)
>
>It would be more than just the pom, though. It would have to be a
>separate project that included the Tika parsers that wrapped these
>non-ASL libraries, or do I misunderstand? Oh, wait, are you suggesting:
>
>Step 1) create the Tika wrapper parser as a standalone project, Step 2)
>publish the L?GPL poms to include both the Tika parsers and their
>dependencies?
>
>
>[1] http://www.apache.org/legal/resolved.html#optional
>
>[2]
>http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201103.mbox/%3C
>AANLkTinJDPtT+53EGA0ddkxLkt5QXiD51go7tJDt1RCG@mail.gmail.com%3E
>
>[3]
>http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201103.mbox/%3C
>D67BF270-EBC8-4ECE-9540-C805A92D0EA0@jaguNET.com%3E
>
>-----Original Message-----
>From: Nick Burch [mailto:apache@gagravarr.org]
>Sent: Friday, February 13, 2015 7:51 AM
>To: dev@tika.apache.org
>Subject: Re: Parser that includes LGPL as "provided"?
>
>On Fri, 13 Feb 2015, Allison, Timothy B. wrote:
>> After I dig myself out of several other issues that I'd like to tackle,
>> I'd like to add a parser for MSAccess files. There's a pure java LGPL
>> library, Jackcess, available on maven, and it appears to be quite
>> active.
>>
>> I know we have a list of third party parsers, but I'm wondering if we
>> could write a Tika parser that uses Jackcess but sets it as "provided"
>> in the pom. This seems to me to be equivalent to our current
>>"excludes"
>> statements for some other LGPL files.
>
>For a non-ASF apache licensed project, that'd probably be ok. However,
>the
>ASF legal policies are a bit stricter.
>
>There's a brief summary here:
>http://www.apache.org/legal/resolved.html#prohibited
>
>And if you check the legal-discuss@ archives
>http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ for LGPL
>you'll see lots of discussion about how optional features which need
>LGPL,
>plugins which need LGPL code etc need to be handled.
>
>If you think you might be able to compe up with a plan that would fit
>within those rules, it's best to run it past the legal-discuss list
>and/or
>raise a legal jira to get it checked. If not, the parser would need to
>live elsewhere and be listed on the third party plugins page, with users
>who are OK with LGPL rules needing to download them themselves.
>
>(Actually, there's nothing stopping someone publishing an "all Tika
>including LGPL" or "all Tika including GPL" pom, which auto-includes
>these for those users who can use things under those licenses in their
>projects, but for policy reasons it couldn't be a PMC action to publish
>that)
>
>Nick
RE: Parser that includes LGPL as "provided"?
Posted by "Allison, Timothy B." <ta...@mitre.org>.
Thank you, Nick.
One answer to ("Will the majority of users want to use my product without adding the optional components?") [1] would be "No, all users are currently using Tika without this optional component. It is just another parser that some might want to use for one file type among many."
However, my takeaway from this discussion on [2], [3] is: don't. Just, don't. Really, don't.
For your suggestion:
>>(Actually, there's nothing stopping someone publishing an "all Tika
>>including LGPL" or "all Tika including GPL" pom, which auto-includes
>>these for those users who can use things under those licenses in their
>>projects, but for policy reasons it couldn't be a PMC action to publish
>>that)
It would be more than just the pom, though. It would have to be a separate project that included the Tika parsers that wrapped these non-ASL libraries, or do I misunderstand? Oh, wait, are you suggesting:
Step 1) create the Tika wrapper parser as a standalone project, Step 2) publish the L?GPL poms to include both the Tika parsers and their dependencies?
[1] http://www.apache.org/legal/resolved.html#optional
[2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201103.mbox/%3CAANLkTinJDPtT+53EGA0ddkxLkt5QXiD51go7tJDt1RCG@mail.gmail.com%3E
[3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201103.mbox/%3CD67BF270-EBC8-4ECE-9540-C805A92D0EA0@jaguNET.com%3E
-----Original Message-----
From: Nick Burch [mailto:apache@gagravarr.org]
Sent: Friday, February 13, 2015 7:51 AM
To: dev@tika.apache.org
Subject: Re: Parser that includes LGPL as "provided"?
On Fri, 13 Feb 2015, Allison, Timothy B. wrote:
> After I dig myself out of several other issues that I'd like to tackle,
> I'd like to add a parser for MSAccess files. There's a pure java LGPL
> library, Jackcess, available on maven, and it appears to be quite
> active.
>
> I know we have a list of third party parsers, but I'm wondering if we
> could write a Tika parser that uses Jackcess but sets it as "provided"
> in the pom. This seems to me to be equivalent to our current "excludes"
> statements for some other LGPL files.
For a non-ASF apache licensed project, that'd probably be ok. However, the
ASF legal policies are a bit stricter.
There's a brief summary here:
http://www.apache.org/legal/resolved.html#prohibited
And if you check the legal-discuss@ archives
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ for LGPL
you'll see lots of discussion about how optional features which need LGPL,
plugins which need LGPL code etc need to be handled.
If you think you might be able to compe up with a plan that would fit
within those rules, it's best to run it past the legal-discuss list and/or
raise a legal jira to get it checked. If not, the parser would need to
live elsewhere and be listed on the third party plugins page, with users
who are OK with LGPL rules needing to download them themselves.
(Actually, there's nothing stopping someone publishing an "all Tika
including LGPL" or "all Tika including GPL" pom, which auto-includes
these for those users who can use things under those licenses in their
projects, but for policy reasons it couldn't be a PMC action to publish
that)
Nick
Re: Parser that includes LGPL as "provided"?
Posted by Nick Burch <ap...@gagravarr.org>.
On Fri, 13 Feb 2015, Allison, Timothy B. wrote:
> After I dig myself out of several other issues that I'd like to tackle,
> I'd like to add a parser for MSAccess files. There's a pure java LGPL
> library, Jackcess, available on maven, and it appears to be quite
> active.
>
> I know we have a list of third party parsers, but I'm wondering if we
> could write a Tika parser that uses Jackcess but sets it as "provided"
> in the pom. This seems to me to be equivalent to our current "excludes"
> statements for some other LGPL files.
For a non-ASF apache licensed project, that'd probably be ok. However, the
ASF legal policies are a bit stricter.
There's a brief summary here:
http://www.apache.org/legal/resolved.html#prohibited
And if you check the legal-discuss@ archives
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ for LGPL
you'll see lots of discussion about how optional features which need LGPL,
plugins which need LGPL code etc need to be handled.
If you think you might be able to compe up with a plan that would fit
within those rules, it's best to run it past the legal-discuss list and/or
raise a legal jira to get it checked. If not, the parser would need to
live elsewhere and be listed on the third party plugins page, with users
who are OK with LGPL rules needing to download them themselves.
(Actually, there's nothing stopping someone publishing an "all Tika
including LGPL" or "all Tika including GPL" pom, which auto-includes
these for those users who can use things under those licenses in their
projects, but for policy reasons it couldn't be a PMC action to publish
that)
Nick
Re: Parser that includes LGPL as "provided"?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Some of the examples of this are to have the external
LGPL library at Github (I remember Jukka Zitting did
a MS TNEF parser that did this) and then just having it
as a separate plugin. I don’t think we should add potential
“surprises” for people expecting Tika to not have any
core deps on LGPL. Nick also has the Vorbis (misspelling
that I know) on Github, not sure if it’s for the same
reason.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Allison>, "Timothy B." <ta...@mitre.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Friday, February 13, 2015 at 4:16 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: Parser that includes LGPL as "provided"?
>All,
> After I dig myself out of several other issues that I'd like to tackle,
>I'd like to add a parser for MSAccess files. There's a pure java LGPL
>library, Jackcess, available on maven, and it appears to be quite active.
> I know we have a list of third party parsers, but I'm wondering if we
>could write a Tika parser that uses Jackcess but sets it as "provided" in
>the pom. This seems to me to be equivalent to our current "excludes"
>statements for some other LGPL files.
> Users would be responsible for grabbing the jar and putting it on
>their classpath, and our parser would check to see if it was available in
>the classpath before parsing or even admitting that it could handle an
>MSAccess file.
> Is this ok? Or would we have to offer the Tika parser as a purely
>third party option, i.e. hang it on github?
>
> Thank you.
>
> Best,
>
> Tim
>
Parser that includes LGPL as "provided"?
Posted by "Allison, Timothy B." <ta...@mitre.org>.
All,
After I dig myself out of several other issues that I'd like to tackle, I'd like to add a parser for MSAccess files. There's a pure java LGPL library, Jackcess, available on maven, and it appears to be quite active.
I know we have a list of third party parsers, but I'm wondering if we could write a Tika parser that uses Jackcess but sets it as "provided" in the pom. This seems to me to be equivalent to our current "excludes" statements for some other LGPL files.
Users would be responsible for grabbing the jar and putting it on their classpath, and our parser would check to see if it was available in the classpath before parsing or even admitting that it could handle an MSAccess file.
Is this ok? Or would we have to offer the Tika parser as a purely third party option, i.e. hang it on github?
Thank you.
Best,
Tim
Re: grib adds ~14 MB to tika-app?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
+1 to removing these resources from tika-server, and not
shipping them with the binary build - can we exclude it from
both tika-server and tika-parsers?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: <Allison>, "Timothy B." <ta...@mitre.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Thursday, February 12, 2015 at 7:04 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: grib adds ~14 MB to tika-app?
>All,
> I just noticed that tika-app has gone from ~30MB to ~44MB, ~20k file to
>~27k files. 3.5 of those new MB are for README.NLDAS1.pdf and
>README.NLDAS2.pdf. Can we exclude those in the app and server? Are
>there other items that we should exclude?
>
>
> Cheers,
>
> Tim