Release candidate is withdrawn.
Karl
On Sat, Aug 16, 2014 at 6:55 AM, Mingchun Zhao
wrote:
> Hi Karl,
>
> Got it.
> I'll spin up the RC1 just now.
>
> Regards,
> Mingchun
>
> 2014-08-15 19:26 GMT+09:00 Karl Wright :
> > The ticket is CONNECTORS-1010, which I have fixed and pulled up a fix for
Hi Karl,
Got it.
I'll spin up the RC1 just now.
Regards,
Mingchun
2014-08-15 19:26 GMT+09:00 Karl Wright :
> The ticket is CONNECTORS-1010, which I have fixed and pulled up a fix for
> 1.7 for.
>
> Mingchun, can you close this vote, and spin up an RC1 that we can vote on?
>
> Thanks!
> Karl
>
>
The ticket is CONNECTORS-1010, which I have fixed and pulled up a fix for
1.7 for.
Mingchun, can you close this vote, and spin up an RC1 that we can vote on?
Thanks!
Karl
On Fri, Aug 15, 2014 at 5:50 AM, Karl Wright wrote:
> Hi Erlend,
>
> This is actually the result of a bug fix that was ma
Hi Erlend,
This is actually the result of a bug fix that was made in the 1.7 time
frame. The problem actually arose in the first place in 1.5, when a lock
needed to go from being a critical section to a cross-process lock. But,
due to an oversight, this was only fixed now.
We can lock based on
Another thing. It's not possible to abort the job due to this problem.
LockManager still tries to set locks over and over again. It's not just
the previous URL/filename I entered, but several others:
WARN 2014-08-15 10:07:46,178 (Worker thread '31') - Attempt to set
file lock
'/www/var/dat
-1
All my first tests pass, but I think I found a blocker when I ran the
last one.
By running MCF using FileLockManager, I'm getting the following error
and MCF just tries to run this task over and over again. My synch folder
now contains a lot of files and it still grows. I think MCF shoul
On 12.08.14 05:13, Mingchun Zhao wrote:
Hi all,
Please vote on whether to release the ManifoldCF, version 1.7, RC0.
You can find the artifact at:
http://people.apache.org/~mingchun/apache-manifoldcf-1.7-RC0
There is also a tag at:
https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.7-
Hi Abe-san,
Actually, for the Tika transformation connector, there are TWO different
mime types. One mime type represents what the connector generates. The
other represents what the connector can accept. This is true of all
transformation connectors.
Hope that helps.
Karl
On Tue, Aug 12, 20
Ok, I understand we specify 'text/plain;charset=utf-8' string temporarily
so that we accept all kinds of mime types.
Thanks,
Shinichiro Abe
2014-08-13 1:25 GMT+09:00 Karl Wright :
> bq. I have a question.
> What is this? -> hard-coded mymetype checkings, "text/plain;charset=utf-8".
> For what?
bq. I have a question.
What is this? -> hard-coded mymetype checkings, "text/plain;charset=utf-8".
For what? This seems to be unnecessary.
http://svn.apache.org/viewvc/manifoldcf/trunk/connectors/tika/connector/src/main/java/org/apache/manifoldcf/agents/transformation/tika/TikaExtractor.java?view=m
Hi Karl,
I also confirmed that using a SJIS file attached on CONNECTORS-613,
then the file was not garbled and could extract content and metadata
properly by tika connector.
Therefore currently we don't need to respin RC.
I have a question.
What is this? -> hard-coded mymetype checkings, "text/pl
Ok, I closed the ticket.
So thanks, I think I'm now read to vote +1.
Karl
On Tue, Aug 12, 2014 at 11:38 AM, Shinichiro Abe wrote:
> I apologize for the mistake, I forgot to configure tika connector in the
> job. I configured documentFilter and Metadata adjuster only.
> It works by adding tik
I apologize for the mistake, I forgot to configure tika connector in the
job. I configured documentFilter and Metadata adjuster only.
It works by adding tika connector, there is no problem. English pdf,
Japanese pdf/xls are not garbled!
I'm sorry! So we don't have to fix CONNECTORS-1008.
Shinichir
Ok, I've done some more experimentation, and confirmed that there is really
only ONE problem: in SolrJ or Solr. ManifoldCF is working perfectly.
The ticket I created, CONNECTORS-1008, will therefore be postponed to MCF
2.0. The workaround is the use the extracting update handler even when the
co
So there are two problems. One problem is that the Tika Extractor is not
doing the right thing (I think). The second problem is that valid
characters are not being sent to Solr when SolrInputDocument is used.
Karl
On Tue, Aug 12, 2014 at 10:15 AM, Shinichiro Abe wrote:
> Thanks Karl,
>
> Wh
Thanks Karl,
When posting MCF's end-user-documentation.pdf(English) via standard update
handler,
Solr throws an exception, this is a problem, I'm not sure why.
It works by leaving my pipeline to include Tika and using the extracting
update handler.
Solr's Tika version matches MCF's Tika one(1.5).
It looks like the Tika content extraction is not actually producing valid
utf-8. I'm not sure what it is producing, but that is the underlying
problem.
I'll create a ticket and look into it.
Karl
On Tue, Aug 12, 2014 at 9:52 AM, Karl Wright wrote:
> Hi Abe-san,
>
> It looks to me like SolrJ
Hi Abe-san,
It looks to me like SolrJ when it uses SolrInputDocument cannot correctly
post some kinds of characters. The exception is coming from inside Solr
itself -- not SolrJ. So I think a Solr ticket would be the right thing to
do here.
Can you try leaving your pipeline to include Tika, but
Hi Karl,
The content field was garbled via /update and tika connector.
Sample Docs: http://www.rondhuit.com/download.html#whitepaper
My mcf-job was from filesystem:Japanese PDF,XLS to Solr.
I was surprised that Solr threw an exception when
en_US end-user-documentation.pdf
was posted via tika conn
I ran "ant rat-sources", and inspected the packages. All looks good. The
only comment is that the connector-lib area has grown by about 18MB this
cycle, and of course all the images for the Chinese documentation add
another 5MB, so our binary packages are now just about 200MB. I don't
think this
Hi Abe-san,
I think TikaExtractor should fully support sjis input at this point. It
should convert extracted sjis content to utf-8.
I know SOLR-6199 is an issue but I want to be sure we have otherwise
completed the Tika connector properly. So that is why I asked you to try
it, but not in produc
Hi Karl
I'm sorry, currently I don't plan to use Tika transformation
because TikaExtractor supports text/plain;charset=utf-8 only and has SOLR-6199
issue.
So, I think TikaExtractor's development is in progress.
I'll try to do that if I have a time though.
Regards,
Shinichiro Abe
On 2014/08/12,
Hi Abe-san,
I wonder if you would be willing to try indexing Koji's site into Solr
using the Tika transformation connection and the Solr standard update
handler? It would be good to know if this works just like the Solr
extracting update handler. If not we should fix it.
Thanks!
Karl
On Tue,
I request that the vote be left open at least until 8/21/2014, since 1.7 is
a major release and we want as many people to try it out as possible before
declaring it complete. Thanks!
Karl
On Tue, Aug 12, 2014 at 12:44 AM, Shinichiro Abe wrote:
> Hi,
>
> +1 from me.
>
> -Checked SIGS, checksu
Hi,
+1 from me.
-Checked SIGS, checksum by running check_signatures.sh.
-Checked that the code signing Key of Mingchun is available online.
Shinichiro Abe
On 2014/08/12, at 12:13, Mingchun Zhao wrote:
> Hi all,
>
> Please vote on whether to release the ManifoldCF, version 1.7, RC0.
>
> You
Additionally checked:
1. ant test(BUILD SUCCESSFUL)
2. chinese(screen,document)
Mingchun
2014-08-12 12:42 GMT+09:00 Mingchun Zhao :
> +1 from me.
> Inspected unpacking(tar.gz, zip), crawling(file system only).
>
> Mingchun
>
> 2014-08-12 12:13 GMT+09:00 Mingchun Zhao :
>> Hi all,
>>
>> Please v
+1 from me.
Inspected unpacking(tar.gz, zip), crawling(file system only).
Mingchun
2014-08-12 12:13 GMT+09:00 Mingchun Zhao :
> Hi all,
>
> Please vote on whether to release the ManifoldCF, version 1.7, RC0.
>
> You can find the artifact at:
>
> http://people.apache.org/~mingchun/apache-manifoldc
Hi all,
Please vote on whether to release the ManifoldCF, version 1.7, RC0.
You can find the artifact at:
http://people.apache.org/~mingchun/apache-manifoldcf-1.7-RC0
There is also a tag at:
https://svn.apache.org/repos/asf/manifoldcf/tags/release-1.7-RC0
Vote will remain open at least 72 hou
28 matches
Mail list logo