Re: Need an opinion, on whether to change package or not
+1 to renaming the package - nows the time. - Mark http://www.lucidimagination.com (mobile) On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" wrote: > +1 > > -- Jack Krupansky > > -- > From: "Karl Wright" > Sent: Sunday, August 22, 2010 1:49 PM > To: "connectors-dev" > Subject: Need an opinion, on whether to change package or not > >> Consider this an official request for a vote. >> >> +1 indicates you think we should change the following in the source code, as >> soon as is practical: >> >> org.apache.lcf.xxx -> org.apache.acf.xxx >> All classes LCF.java and LCFException.java should change to ACF.java and >> ACFException.java >> >> Bear in mind that users of ACF/LCF who currently have existing database >> instances will need to reinitialize those instances if we do this change. >> This is because the class names of connectors are stored in the database >> when the connector is registered. >> >> (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I >> will of course abide by the consensus.) >> >> Vote will be considered closed by Wednesday evening, so vote early (and >> often. ;-)) >> Karl
Re: Need an opinion, on whether to change package or not
+1 -- Jack Krupansky -- From: "Karl Wright" Sent: Sunday, August 22, 2010 1:49 PM To: "connectors-dev" Subject: Need an opinion, on whether to change package or not Consider this an official request for a vote. +1 indicates you think we should change the following in the source code, as soon as is practical: org.apache.lcf.xxx -> org.apache.acf.xxx All classes LCF.java and LCFException.java should change to ACF.java and ACFException.java Bear in mind that users of ACF/LCF who currently have existing database instances will need to reinitialize those instances if we do this change. This is because the class names of connectors are stored in the database when the connector is registered. (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I will of course abide by the consensus.) Vote will be considered closed by Wednesday evening, so vote early (and often. ;-)) Karl
Re: Need an opinion, on whether to change package or not
Karl, is the Fully-Qualified classname in the DB the only problem? I mean you would break all kinds of BW compat if you change the package names. All imports must be fixed etc. One thing I don't get is that LCF has not yet been released, right?! We can fix the DB issues in the code very easily but fixing the import thing etc. is not that easy. I don't see any reason why we should hesitate to rename the package names on an unreleased trunk. People who use trunk follow a moving target anyway. BTW: Did the name change vote succeed? here is my +1 on the package name change provided my assumption above are correct and if the name change vote was successful. simon On Sun, Aug 22, 2010 at 7:49 PM, Karl Wright wrote: > Consider this an official request for a vote. > > +1 indicates you think we should change the following in the source code, as > soon as is practical: > > org.apache.lcf.xxx -> org.apache.acf.xxx > All classes LCF.java and LCFException.java should change to ACF.java and > ACFException.java > > Bear in mind that users of ACF/LCF who currently have existing database > instances will need to reinitialize those instances if we do this change. > This is because the class names of connectors are stored in the database > when the connector is registered. > > (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I > will of course abide by the consensus.) > > Vote will be considered closed by Wednesday evening, so vote early (and > often. ;-)) > Karl >
Need an opinion, on whether to change package or not
Consider this an official request for a vote. +1 indicates you think we should change the following in the source code, as soon as is practical: org.apache.lcf.xxx -> org.apache.acf.xxx All classes LCF.java and LCFException.java should change to ACF.java and ACFException.java Bear in mind that users of ACF/LCF who currently have existing database instances will need to reinitialize those instances if we do this change. This is because the class names of connectors are stored in the database when the connector is registered. (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I will of course abide by the consensus.) Vote will be considered closed by Wednesday evening, so vote early (and often. ;-)) Karl
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901193#action_12901193 ] Karl Wright commented on CONNECTORS-91: --- Yes, your trunk version is too out of date. For example: kwri...@osore:~/wip/lcf-command-patch$ svn info trunk/modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java Path: trunk/modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java Name: SynchronizeAll.java URL: https://svn.apache.org/repos/asf/incubator/lcf/trunk/modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 987926 Node Kind: file Schedule: normal Last Changed Author: kwright Last Changed Rev: 921329 Last Changed Date: 2010-03-10 07:44:20 -0500 (Wed, 10 Mar 2010) Text Last Updated: 2010-08-22 12:50:36 -0400 (Sun, 22 Aug 2010) Checksum: 42dcca2a9eab1c6d5b48bdcd5c083a0b ... and the patch says: Index: modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java === --- modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java (revision 987465) +++ modules/framework/agents/org/apache/lcf/agents/SynchronizeAll.java (working copy) so, I am afraid you will need to synch up and reissue the patch. > Making the initialization commands more useable > --- > > Key: CONNECTORS-91 > URL: https://issues.apache.org/jira/browse/CONNECTORS-91 > Project: Apache Connectors Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jettro Coenradie > Fix For: LCF Release 0.5 > > Attachments: changesToCommandClasses.patch, commandsPatch.patch > > > At the moment LCF comes with some classes that can be used to run command > line to interact with the system. Examples are DBCreate, DBDrop and > LockClean. I wanted to create a class that rebuilds my complete environment. > So dropping a database, creating a database, cleaning the synch folder, > registering agents, etc. Due to the structure of the classes with all the > logic in the main method, I could not easily reuse these classes. In the > patch I submit with issue I have refactored the current solution in a better > reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable
[ https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901186#action_12901186 ] Karl Wright commented on CONNECTORS-91: --- The patch failed to apply, fairly catastrophically. Only some 50% of files actually patched successfully. I don't know why this happened yet. Are you synchronized with the current version of trunk? Karl > Making the initialization commands more useable > --- > > Key: CONNECTORS-91 > URL: https://issues.apache.org/jira/browse/CONNECTORS-91 > Project: Apache Connectors Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jettro Coenradie > Fix For: LCF Release 0.5 > > Attachments: changesToCommandClasses.patch, commandsPatch.patch > > > At the moment LCF comes with some classes that can be used to run command > line to interact with the system. Examples are DBCreate, DBDrop and > LockClean. I wanted to create a class that rebuilds my complete environment. > So dropping a database, creating a database, cleaning the synch folder, > registering agents, etc. Due to the structure of the classes with all the > logic in the main method, I could not easily reuse these classes. In the > patch I submit with issue I have refactored the current solution in a better > reuseable solution that can still be called command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Moving test support classes
Are any of these classes generally usable outside of LCF/ACF, such as by an integrator or administrator who wants some scriptable control over crawl jobs, as opposed to internal product testing? If so, maybe there should be third category, say "public" or "utility". -- Jack Krupansky -- From: "Jettro Coenradie" Sent: Sunday, August 22, 2010 2:03 AM To: Subject: Moving test support classes Hi, I see a lot of classes that contain the comment : "This class is used during testing." Is it a good idea to move this classes to a separate package or even better, closer to the tests? That way they do not pollute the normal code base. a few examples: org.apache.lcf.crawler.AbortJob org.apache.lcf.crawler.AddScheduledTime org.apache.lcf.crawler.ChangeJobDocSpec etc regards -- Jettro Coenradie http://www.gridshore.nl
