Re: Please welcome Hitoshi Ozawa to the ManifoldCF community!
(12/02/07 11:39), Karl Wright wrote: Hitoshi is now officially a ManifoldCF Committer. Congratulations, Hitoshi! Karl Congrats Ozawa-san! koji -- http://www.rondhuit.com/en/
[jira] [Commented] (CONNECTORS-314) Combined MySQL and i18n/Japanese contribution
[ https://issues.apache.org/jira/browse/CONNECTORS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175156#comment-13175156 ] Koji Sekiguchi commented on CONNECTORS-314: --- Right. I thought that, too. They should be removed in svn. Combined MySQL and i18n/Japanese contribution - Key: CONNECTORS-314 URL: https://issues.apache.org/jira/browse/CONNECTORS-314 Project: ManifoldCF Issue Type: Improvement Components: Framework agents process, Framework core, Framework crawler agent Affects Versions: ManifoldCF 0.5 Reporter: Karl Wright Assignee: Karl Wright Labels: I18N, mysql Fix For: ManifoldCF 0.5 Attachments: CONNECTORS-314-doc20111220.patch, CONNECTORS-314.patch, CONNECTORS-314.patch, connectors.patch, framework.patch Hitoshi Ozawa wishes to contribute i18n support, a Japanese localization, and MySQL database support, all in one patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The burning technical issues of the day
I've been thinking mock for unit test, too. Does anyone know there are any projects that connect proprietary software in Apache? We can consult them, if any. Tommaso, do you know Alchemy Annotator uses mock for the test in UIMA? Koji -- http://www.rondhuit.com/en/ (11/05/17 22:10), Tommaso Teofili wrote: Hello Karl, thanks so much again for the warm welcome and for these insights. I agree with you that testability is a major concern we need to engage and get sorted. One thing I think right now is that having tests rely on a testing infrastructure would possibly expose ManifoldCF to this issue again in case of maintenance, versions evolution and so on therefore, although I still have to investigate if that can be sorted technically for the supported systems, my design time opinion is that we should try to mock those systems. Did you try to mock any of them yet? Does this sound good/bad to you? Regards, Tommaso 2011/5/17 Karl Wrightdaddy...@gmail.com For those who have just entered the ManifoldCF project, I'd like to first extend my congratulations once again! You are probably still trying to figure out exactly what's going on and where we are going. Unfortunately, this being Apache, I cannot actually answer your question, because you are part of the process now, and you will now be able to act on your own ideas and goals for the project. But in the interests of planning and consensus building, I'd like to share my thoughts as to what I think are the major technical issues the project faces. The first and foremost issue is one of testability. ManifoldCF is unique in that every connector requires a system to test against. In some cases this is a proprietary system, such as Documentum or LiveLink. In other cases, it's a large number of web servers. When MetaCarta developed the project in the first place, we had a stable of VMs against which our tests worked. They had proprietary software installed in some cases, or some Apache hackery to emulate a large number of individual web sites. When MetaCarta assets were sold to qBase, those assets included those VMs. We desperately need something like this again. I've tried to get access to the old MetaCarta VM's, but qBase has not yet granted this, and may never grant it due to ongoing technical reasons. Given this, it seems that we need some way of doing the same thing. It would be great to hear your ideas, especially if you have access to any of the proprietary systems we support and would be willing to set up and maintain testing infrastructure. Again, welcome to our new committers and new mentor! Karl
Re: [VOTE] Release ManifoldCF-0.2-incubating, RC1
(11/04/01 19:24), Karl Wright wrote: RC1 is now available on http://people.apache.org/~kwright/apache-manifoldcf-0.2-incubating. Please check it out and vote! Karl +1. I checked all .md5/.asc files, did ant test, ant javadoc and read CHANGES.txt, etc. Koji -- http://www.rondhuit.com/en/
Re: [VOTE] Release ManifoldCF-0.2-incubating
(11/03/21 9:32), Karl Wright wrote: The tag is https://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.2-incubating-RC0. You can download the candidate from http://people.apache.org/~kwright/apache-manifoldcf-0.2-incubating. Hi Karl, I downloaded apache-manifoldcf-0.2-incubating-bin.tar.gz and did ant test, but I got Database exception: Exception doing query: No current connection. exception during the test. I'm not sure it is same as CONNECTORS-172. Are you digging in the issue and planning to respin the RC? Koji -- http://www.rondhuit.com/en/
Re: Reopened CONNECTORS-148; should we spin an RC9?
+1. release the artifacts that are voted on. Koji (11/02/01 10:15), Robert Muir wrote: Just my opinion: 1. release the artifacts that are voted on... its 0.1 and a lot of people will likely be still in evaluation stage (likely with derby?). Obviously there are bugs, even ones that aren't known, but I think its just fine to release with known bugs... better at this stage to get the release out there and possibly draw in more people (who might find more bugs). 2. start working on the next release. besides this bug, for example there is the related issue open for improved postgresql testing, etc: personally I think this is great, maybe expanding on that idea could uncover even more bugs. the known bugs are documented in jira anyway, but workarounds or whatever could be put in the wiki in the meantime too. I don't think the next release needs to be rushed out to fix the bug quickly, either. Its not the end of the world at this point if people hit the bug and are drawn into mailing lists/svn/jira/whatever On Mon, Jan 31, 2011 at 5:37 PM, Karl Wrightdaddy...@gmail.com wrote: There is a workaround, but given the fact that a complex workaround is needed to execute what should be a simple deployment, I'd wonder if we have our priorities straight in releasing 0.1 in this condition. But it's your call. The release process is easy for me, except the pain needed to get everyone to have a look at the artifact and sign off on it, and I can see no particular rush either. If we do have another RC, I would also like to add Postgresql-based tests into RC9. I've got them just about ready, and will be committing to trunk shortly. Karl On Mon, Jan 31, 2011 at 4:19 PM, Grant Ingersollgsing...@apache.org wrote: Is there a workaround for the issue? Can't the user create it by hand? On Jan 31, 2011, at 1:51 AM, Karl Wright wrote: You can read the details in CONNECTORS-148. I hesitate to ask this because getting the votes for RC8 just finished, and took the better part of a month, but should we produce an RC9? This issue was considered a blocker for release, and since it appears to not have been fixed, I really think we have no choice. Effectively this prevents people from using PostgreSQL with ManifoldCF, unless they take manual measures, and I doubt many people will be willing to do that. Karl -- http://www.rondhuit.com/en/
Re: [VOTE] Release Apache ManifoldCF 0.1 Incubating, RC8
(11/01/17 17:04), Karl Wright wrote: C'mon, guys - we just need two more binding PMC votes... Karl On Tue, Jan 11, 2011 at 10:19 PM, Karl Wrightdaddy...@gmail.com wrote: RC8 is ready. This fixes the problems found in CONNECTORS-149. Find it at: http://people.apache.org/~kwright/apache-manifoldcf-0.1-incubating The svn tag URL is http://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.1-incubating-RC8 Please evaluate the candidate, and if you find it OK then vote. I've completed my review of the deletion/expiration code, and although there are a couple of other tickets from that review, they do not (in my opinion) warrant holding the release. +1 from me. Karl Hi Karl, +1. ran test, javadoc, rat-sources, etc on my Mac and looked at *.txt. Looks fine. Sorry for the late vote. Koji -- http://www.rondhuit.com/en/
Re: Derby/JUnit bad interaction - any ideas?
(10/06/08 22:35), karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Hi Karl, If it is possible, Ant chmod task can be used, or you can consult the implementation. But Ant manual says for the task: Right now it has effect only under Unix or NonStop Kernel (Tandem). http://ant.apache.org/manual/Tasks/chmod.html Koji -- http://www.rondhuit.com/en/
Re: Derby/JUnit bad interaction - any ideas?
(10/06/08 23:14), karl.wri...@nokia.com wrote: Yeah, I was pretty surprised too. But on windows it is likely that File.makeReadOnly() (which is what Derby must be using) doesn't actually do anything to directories, which would explain the discrepancy. Karl If so, luckily Ant hack can solve the problem on Linux. Koji -- http://www.rondhuit.com/en/
