[jira] [Commented] (TIKA-1558) Create a Parser Blacklist
[
https://issues.apache.org/jira/browse/TIKA-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334779#comment-14334779
]
Nick Burch commented on TIKA-1558:
--
I've updated the Tika Config example in
https://wiki.apache.org/tika/CompositeParserDiscussion#With_a_Tika_Configuration_file
to show how I see a parser-exclude (blacklist) working in config with
DefaultParser.
If people think that looks OK, I can add support for that pretty easily and
quickly, I think!
Create a Parser Blacklist
-
Key: TIKA-1558
URL: https://issues.apache.org/jira/browse/TIKA-1558
Project: Tika
Issue Type: New Feature
Reporter: Tyler Palsulich
Assignee: Tyler Palsulich
Fix For: 1.8
As talked about in TIKA-1555 and TIKA-1557, it would be nice to be able to
disable Parsers without pulling their dependencies out. In some cases (e.g.
disable all ExternalParsers), there may not be an easy way to exclude the
dependencies via Maven.
So, an initial design would be to include another file like
{{META-INF/services/org.apache.tika.parser.Parser.blacklist}}. We create a
new method {{ServiceLoader#loadServiceProviderBlacklist}}. Then, in
{{ServiceLoader#loadServiceProviders}}, we remove all elements of the list
that are assignable to an element in
{{ServiceLoader#loadServiceProviderBlacklist}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tika pull request: Update README.md
GitHub user chrismattmann opened a pull request: https://github.com/apache/tika/pull/31 Update README.md Add in github contribution instructions You can merge this pull request into a Git repository by running: $ git pull https://github.com/chrismattmann/tika patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tika/pull/31.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #31 commit 9145c7f059cab90cb852aa0207ea57d6818d884b Author: Chris Mattmann chris.mattm...@gmail.com Date: 2015-02-24T15:27:14Z Update README.md Add in github contribution instructions --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [netcdfgroup] Which mime-types for NetCDF3 and NetCDF-4C?
Hi Daniele, Great question. I think the NetCDF folks at UCAR are the best folks to answer this, but since it applies to downstream libraries that implement MIME support for NetCDF (detection/parsing) like Apache Tika, I’m going to CC the Apache Tika list to keep them abreast of this conversation. Cheers, Chris ++ 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.mattm...@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: Daniele Romagnoli daniele.romagn...@geo-solutions.it Date: Tuesday, February 24, 2015 at 9:35 AM To: netcdfgr...@unidata.ucar.edu netcdfgr...@unidata.ucar.edu, Java NetCDF netcdf-j...@unidata.ucar.edu Subject: [netcdfgroup] Which mime-types for NetCDF3 and NetCDF-4C? Hi lists. First of all, sorry for cross-posting. Looking around, I see that the mimeType for NetCDF is application/x-netcdf. Are specific mimetypes be defined to distinguish between NetCDF3 and NetCDF-4C? Cheers, Daniele == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Daniele Romagnoli Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
[jira] [Commented] (TIKA-1483) Create a general raw string parser
[
https://issues.apache.org/jira/browse/TIKA-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336144#comment-14336144
]
Giuseppe Totaro commented on TIKA-1483:
---
Hi [~chrismattmann], I don't know why but sometimes the {{patch}} tool does not
work well if there is not a newline at the end of file.
On my laptop, the patch works well if you put a new line at the end of file
(e.g., {{printf \n TIKA-1483_v2.patch}}).
I hope this trivial trick may be useful.
Thank you,
Giuseppe
Create a general raw string parser
--
Key: TIKA-1483
URL: https://issues.apache.org/jira/browse/TIKA-1483
Project: Tika
Issue Type: New Feature
Components: parser
Affects Versions: 1.6
Reporter: Luis Filipe Nassif
Attachments: TIKA-1483.patch, TIKA-1483_v2.patch
I think it can be very useful adding a general parser able to extract raw
strings from files (like the strings command), which can be used as the
fallback parser for all mimetypes not having a specific parser
implementation, like application/octet-stream. It can also be used as a
fallback for corrupt files throwing a TikaException.
It must be configured with the script/language to be extracted from the files
(currently I implemented one specific for Latin1).
It can use heuristics to extract strings encoded with different charsets
within the same file, mainly the common ISO-8859-1, UTF8 and UTF16.
What the community thinks about that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1541) StringsParser: a simple strings-based parser for Tika
[
https://issues.apache.org/jira/browse/TIKA-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336157#comment-14336157
]
Hudson commented on TIKA-1541:
--
SUCCESS: Integrated in tika-trunk-jdk1.7 #507 (See
[https://builds.apache.org/job/tika-trunk-jdk1.7/507/])
Updated tests for TIKA-1541 simple strings parser from Guiseppe Totaro.
(mattmann: http://svn.apache.org/viewvc/tika/trunk/?view=revrev=1662173)
*
/tika/trunk/tika-parsers/src/test/resources/test-properties/StringsConfig-full.properties
*
/tika/trunk/tika-parsers/src/test/resources/test-properties/StringsConfig-partial.properties
Updated tests for TIKA-1541 simple strings parser from Guiseppe Totaro.
(mattmann: http://svn.apache.org/viewvc/tika/trunk/?view=revrev=1662171)
*
/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsConfig.java
*
/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsEncoding.java
*
/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsParser.java
*
/tika/trunk/tika-parsers/src/test/java/org/apache/tika/parser/strings/StringsConfigTest.java
*
/tika/trunk/tika-parsers/src/test/java/org/apache/tika/parser/strings/StringsParserTest.java
StringsParser: a simple strings-based parser for Tika
-
Key: TIKA-1541
URL: https://issues.apache.org/jira/browse/TIKA-1541
Project: Tika
Issue Type: Improvement
Components: parser
Reporter: Giuseppe Totaro
Assignee: Chris A. Mattmann
Fix For: 1.8
Attachments: TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmannBurchNassif.020715.patch,
TIKA-1541.TotaroMattmannBurchNassif.020815.patch,
TIKA-1541.TotaroMattmannBurchNassif.020915.patch, TIKA-1541.patch,
TIKA-1541.v02.02182015.patch, testOCTET_header.dbase3
I thought to implement an extremely simple implementation of
{{StringsParser}}, a parser based on the {{strings}} command (or
{{strings}}-alternative command), instead of using the dummy {{EmptyParser}}
for undetected files. It is a preliminary work (you can see a lot of todos).
It is inspired by the work on {{TesseractOCRParser}}. You can find the patch
in attachment.
I created a GitHub
[repository|https://github.com/giuseppetotaro/StringsParser] for sharing the
code. As first test, you can clone the repo, build the code using the
{{build.sh}} script, and then run the parser using the {{run.sh}} script on
some [govdocs1|http://digitalcorpora.org/corpora/govdocs] files (grabbed from
016 subset) detected as {{application/octet-stream}}. The latter script
launches a simple {{StringsTest}} class for testing.
I hope you will find the {{StringsParser}} a good solution for extracting
ASCII strings from undetected filetypes. As far as I understood, many
sophisticated forensics tools work in a similar manner for indexing
purposes. They use a sort of {{strings}} command against files that they are
not able to detect.
In addition to run {{strings}} on undetected files, the {{StringsParser}}
launches the {{file}} command on undetected files and then writes the output
in the {{strings:file_output}} property (I noticed that sometimes the
{{file}} command is able to detect the media type for documents not detected
by Tika).
Finally, you can fine an old discussion about this topic
[here|http://lucene.472066.n3.nabble.com/Default-MIME-Type-td645215.html].
Thanks [~chrismattmann].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1541) StringsParser: a simple strings-based parser for Tika
[
https://issues.apache.org/jira/browse/TIKA-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336101#comment-14336101
]
Chris A. Mattmann commented on TIKA-1541:
-
All tests pass, [~gostep] going to commit your updated tests now!
StringsParser: a simple strings-based parser for Tika
-
Key: TIKA-1541
URL: https://issues.apache.org/jira/browse/TIKA-1541
Project: Tika
Issue Type: Improvement
Components: parser
Reporter: Giuseppe Totaro
Assignee: Chris A. Mattmann
Fix For: 1.8
Attachments: TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmannBurchNassif.020715.patch,
TIKA-1541.TotaroMattmannBurchNassif.020815.patch,
TIKA-1541.TotaroMattmannBurchNassif.020915.patch, TIKA-1541.patch,
TIKA-1541.v02.02182015.patch, testOCTET_header.dbase3
I thought to implement an extremely simple implementation of
{{StringsParser}}, a parser based on the {{strings}} command (or
{{strings}}-alternative command), instead of using the dummy {{EmptyParser}}
for undetected files. It is a preliminary work (you can see a lot of todos).
It is inspired by the work on {{TesseractOCRParser}}. You can find the patch
in attachment.
I created a GitHub
[repository|https://github.com/giuseppetotaro/StringsParser] for sharing the
code. As first test, you can clone the repo, build the code using the
{{build.sh}} script, and then run the parser using the {{run.sh}} script on
some [govdocs1|http://digitalcorpora.org/corpora/govdocs] files (grabbed from
016 subset) detected as {{application/octet-stream}}. The latter script
launches a simple {{StringsTest}} class for testing.
I hope you will find the {{StringsParser}} a good solution for extracting
ASCII strings from undetected filetypes. As far as I understood, many
sophisticated forensics tools work in a similar manner for indexing
purposes. They use a sort of {{strings}} command against files that they are
not able to detect.
In addition to run {{strings}} on undetected files, the {{StringsParser}}
launches the {{file}} command on undetected files and then writes the output
in the {{strings:file_output}} property (I noticed that sometimes the
{{file}} command is able to detect the media type for documents not detected
by Tika).
Finally, you can fine an old discussion about this topic
[here|http://lucene.472066.n3.nabble.com/Default-MIME-Type-td645215.html].
Thanks [~chrismattmann].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1541) StringsParser: a simple strings-based parser for Tika
[
https://issues.apache.org/jira/browse/TIKA-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336103#comment-14336103
]
Chris A. Mattmann commented on TIKA-1541:
-
Committed!
{noformat}
[chipotle:~/tmp/tika] mattmann% svn commit -m Updated tests for TIKA-1541
simple strings parser from Guiseppe Totaro.
Sending
tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsConfig.java
Sending
tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsEncoding.java
Sending
tika-parsers/src/main/java/org/apache/tika/parser/strings/StringsParser.java
Sending
tika-parsers/src/test/java/org/apache/tika/parser/strings/StringsConfigTest.java
Sending
tika-parsers/src/test/java/org/apache/tika/parser/strings/StringsParserTest.java
Transmitting file data .
Committed revision 1662171.
[chipotle:~/tmp/tika] mattmann%
{noformat}
StringsParser: a simple strings-based parser for Tika
-
Key: TIKA-1541
URL: https://issues.apache.org/jira/browse/TIKA-1541
Project: Tika
Issue Type: Improvement
Components: parser
Reporter: Giuseppe Totaro
Assignee: Chris A. Mattmann
Fix For: 1.8
Attachments: TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmann.020615.patch.txt,
TIKA-1541.TotaroMattmannBurchNassif.020715.patch,
TIKA-1541.TotaroMattmannBurchNassif.020815.patch,
TIKA-1541.TotaroMattmannBurchNassif.020915.patch, TIKA-1541.patch,
TIKA-1541.v02.02182015.patch, testOCTET_header.dbase3
I thought to implement an extremely simple implementation of
{{StringsParser}}, a parser based on the {{strings}} command (or
{{strings}}-alternative command), instead of using the dummy {{EmptyParser}}
for undetected files. It is a preliminary work (you can see a lot of todos).
It is inspired by the work on {{TesseractOCRParser}}. You can find the patch
in attachment.
I created a GitHub
[repository|https://github.com/giuseppetotaro/StringsParser] for sharing the
code. As first test, you can clone the repo, build the code using the
{{build.sh}} script, and then run the parser using the {{run.sh}} script on
some [govdocs1|http://digitalcorpora.org/corpora/govdocs] files (grabbed from
016 subset) detected as {{application/octet-stream}}. The latter script
launches a simple {{StringsTest}} class for testing.
I hope you will find the {{StringsParser}} a good solution for extracting
ASCII strings from undetected filetypes. As far as I understood, many
sophisticated forensics tools work in a similar manner for indexing
purposes. They use a sort of {{strings}} command against files that they are
not able to detect.
In addition to run {{strings}} on undetected files, the {{StringsParser}}
launches the {{file}} command on undetected files and then writes the output
in the {{strings:file_output}} property (I noticed that sometimes the
{{file}} command is able to detect the media type for documents not detected
by Tika).
Finally, you can fine an old discussion about this topic
[here|http://lucene.472066.n3.nabble.com/Default-MIME-Type-td645215.html].
Thanks [~chrismattmann].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1483) Create a general raw string parser
[
https://issues.apache.org/jira/browse/TIKA-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336107#comment-14336107
]
Chris A. Mattmann commented on TIKA-1483:
-
[~lfcnassif] I tried to apply this patch and am getting this:
{noformat}
[chipotle:~/tmp/tika] mattmann% patch -p1 TIKA-1483_v2.patch
patching file
tika-parsers/src/main/java/org/apache/tika/parser/strings/Latin1StringsParser.java
patching file
tika-parsers/src/test/java/org/apache/tika/parser/strings/Latin1StringsParserTest.java
patch unexpectedly ends in middle of line
patch: malformed patch at line 403:
[chipotle:~/tmp/tika] mattmann%
{noformat}
Any ideas?
Create a general raw string parser
--
Key: TIKA-1483
URL: https://issues.apache.org/jira/browse/TIKA-1483
Project: Tika
Issue Type: New Feature
Components: parser
Affects Versions: 1.6
Reporter: Luis Filipe Nassif
Attachments: TIKA-1483.patch, TIKA-1483_v2.patch
I think it can be very useful adding a general parser able to extract raw
strings from files (like the strings command), which can be used as the
fallback parser for all mimetypes not having a specific parser
implementation, like application/octet-stream. It can also be used as a
fallback for corrupt files throwing a TikaException.
It must be configured with the script/language to be extracted from the files
(currently I implemented one specific for Latin1).
It can use heuristics to extract strings encoded with different charsets
within the same file, mainly the common ISO-8859-1, UTF8 and UTF16.
What the community thinks about that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1483) Create a general raw string parser
[
https://issues.apache.org/jira/browse/TIKA-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336150#comment-14336150
]
Chris A. Mattmann commented on TIKA-1483:
-
That fixed it [~gostep]! Thanks all tests are passing for me. +1 to commit
this. If there are no objections in the next 24 hours I'll commit it.
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Tika parent . SUCCESS [ 1.821 s]
[INFO] Apache Tika core ... SUCCESS [ 21.645 s]
[INFO] Apache Tika parsers SUCCESS [02:06 min]
[INFO] Apache Tika XMP SUCCESS [ 2.072 s]
[INFO] Apache Tika serialization .. SUCCESS [ 2.382 s]
[INFO] Apache Tika application SUCCESS [ 14.697 s]
[INFO] Apache Tika OSGi bundle SUCCESS [ 17.896 s]
[INFO] Apache Tika server . SUCCESS [ 21.473 s]
[INFO] Apache Tika translate .. SUCCESS [ 2.746 s]
[INFO] Apache Tika examples ... SUCCESS [ 5.429 s]
[INFO] Apache Tika Java-7 Components .. SUCCESS [ 2.680 s]
[INFO] Apache Tika SUCCESS [ 0.038 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 03:39 min
[INFO] Finished at: 2015-02-24T23:32:12-08:00
[INFO] Final Memory: 100M/1653M
[INFO]
[chipotle:~/tmp/tika] mattmann%
{noformat}
Create a general raw string parser
--
Key: TIKA-1483
URL: https://issues.apache.org/jira/browse/TIKA-1483
Project: Tika
Issue Type: New Feature
Components: parser
Affects Versions: 1.6
Reporter: Luis Filipe Nassif
Attachments: TIKA-1483.patch, TIKA-1483_v2.patch
I think it can be very useful adding a general parser able to extract raw
strings from files (like the strings command), which can be used as the
fallback parser for all mimetypes not having a specific parser
implementation, like application/octet-stream. It can also be used as a
fallback for corrupt files throwing a TikaException.
It must be configured with the script/language to be extracted from the files
(currently I implemented one specific for Latin1).
It can use heuristics to extract strings encoded with different charsets
within the same file, mainly the common ISO-8859-1, UTF8 and UTF16.
What the community thinks about that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TIKA-1483) Create a general raw string parser
[ https://issues.apache.org/jira/browse/TIKA-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann reassigned TIKA-1483: --- Assignee: Chris A. Mattmann Create a general raw string parser -- Key: TIKA-1483 URL: https://issues.apache.org/jira/browse/TIKA-1483 Project: Tika Issue Type: New Feature Components: parser Affects Versions: 1.6 Reporter: Luis Filipe Nassif Assignee: Chris A. Mattmann Attachments: TIKA-1483.patch, TIKA-1483_v2.patch I think it can be very useful adding a general parser able to extract raw strings from files (like the strings command), which can be used as the fallback parser for all mimetypes not having a specific parser implementation, like application/octet-stream. It can also be used as a fallback for corrupt files throwing a TikaException. It must be configured with the script/language to be extracted from the files (currently I implemented one specific for Latin1). It can use heuristics to extract strings encoded with different charsets within the same file, mainly the common ISO-8859-1, UTF8 and UTF16. What the community thinks about that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [netcdf-java] [netcdfgroup] Which mime-types for NetCDF3 and NetCDF-4C?
Hi Daniele, THREDDS defines two mime-types for NetCDF: NetCDF3: application/x-netcdf NetCDF4: application/x-netcdf4 I can confirm that the HTTPServer service will return the application/x-netcdf4 mime-type if the underlying file is NetCDF 4. Also, the NetcdfSubset service will return the application/x-netcdf4 mime-type if the netcdf4 output format is selected. Cheers, Christian On Tue, Feb 24, 2015 at 10:38 AM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Daniele, Great question. I think the NetCDF folks at UCAR are the best folks to answer this, but since it applies to downstream libraries that implement MIME support for NetCDF (detection/parsing) like Apache Tika, I’m going to CC the Apache Tika list to keep them abreast of this conversation. Cheers, Chris ++ 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.mattm...@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: Daniele Romagnoli daniele.romagn...@geo-solutions.it Date: Tuesday, February 24, 2015 at 9:35 AM To: netcdfgr...@unidata.ucar.edu netcdfgr...@unidata.ucar.edu, Java NetCDF netcdf-j...@unidata.ucar.edu Subject: [netcdfgroup] Which mime-types for NetCDF3 and NetCDF-4C? Hi lists. First of all, sorry for cross-posting. Looking around, I see that the mimeType for NetCDF is application/x-netcdf. Are specific mimetypes be defined to distinguish between NetCDF3 and NetCDF-4C? Cheers, Daniele == GeoServer Professional Services from the experts! Visit http://goo.gl/NWWaa2 for more information. == Ing. Daniele Romagnoli Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. ___ netcdf-java mailing list netcdf-j...@unidata.ucar.edu For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
[GitHub] tika pull request: Update README.md
Github user asfgit closed the pull request at: https://github.com/apache/tika/pull/31 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
