[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management
[ https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904561#action_12904561 ] Jettro Coenradie commented on CONNECTORS-92: As for the start.jar I do not see a problem. I think I am almost there. THe classpath already contains the lib part, so I only need to add the dependencies to the jetty runner project. As for the example code, I do not mind to keep using and to create the example. I only wanted to have maven to make it easier to setup my development environment and to do the dependency management. I'll try to come up with an improve pom for the start.jar, if that is not enough please let me know. Move from ant to maven or other build system with decent library management --- Key: CONNECTORS-92 URL: https://issues.apache.org/jira/browse/CONNECTORS-92 Project: Apache Connectors Framework Issue Type: Wish Components: Build Reporter: Jettro Coenradie Assignee: Karl Wright Attachments: maven-poms-including-start-jar.patch, maven-poms-problem-starting-jetty-and-derby.patch, move-to-maven-acf-framework.patch, Screen shot 2010-08-23 at 16.31.07.png I am looking at the current project structure. If we want to make another build tool available I think we need to change the directory structure. I tried to place a suggestion in an image. Can you please have a look at it. If we agree that this is a good way to go, than I will continue to work on a patch. Which might be a bit hard with all these changing directories, but I'll do my best to at least get an idea whether it would be working. So I have three questions: - Do you want to move to maven or put maven next to ant? - Do you prefer another build mechanism [ant with ivy, gradle, maven3] - Do you have an idea about the amount of scripts that need to be changed if we change the project structure The image of a possible project layout (that is based on the maven standards) is attached to the issue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-41) Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc.
[ https://issues.apache.org/jira/browse/CONNECTORS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904582#action_12904582 ] Karl Wright commented on CONNECTORS-41: --- I looked at this in some detail yesterday. The prime implementation option is to add notification methods to IOutputConnector, so that job events get reported to the connector when the job is being terminated. The issue in this case is going to be how exactly to handle ServiceInterruption exceptions that occur at the time of the notification into the connector. This is not hypothetical because in the Solr case a notification may well fail, or it may take a very long time (many minutes). Usually when there is a possibility of extended interaction it argues for an additional state in the database. It looks like it will not be possible to delay the change of the job status, since that takes place in a transaction. If the notification fails, the job could otherwise be left in the running state, and a retry would naturally occur until the commit succeeded. But that doesn't look possible given the transaction structure. An alternative (non-notification) method of handling a commit request would require the commit to take place as part of the output connector's poll() method. This is a little better to work with because the poll() method will naturally retry in any case. The issue here is that there would be no *guarantee* of a commit taking place at all, since it isn't part of the connector contract that the connection must continue to exist for any period of time, which I think would violate the spirit of this ticket. If explicit notification takes place, we could just report any error, and forget about it, rather than keeping the job alive for a retry. That, too, would mean that a commit was not guaranteed to occur during the job's lifecycle. The final alternative, which would seemingly work, would involve there being two job shutdown states - one prior to notification, and the second after notification. The first state would be entered based on the current shutdown logic. The second state would be entered only after the notification had been successful. Thus, the notification *could* be called more than once, if there were errors, or if the crawler were shut down and restarted before the state transition was completed. The extra state would also allow the job's pre-notification status to be noted in the crawler ui. Because of the potential time delay of a commit, it is probably best for the first to second shutdown state transition to be handled by a separate thread, or family of threads. Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc. --- Key: CONNECTORS-41 URL: https://issues.apache.org/jira/browse/CONNECTORS-41 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Karl Wright Priority: Minor Currently there is no logic that informs an output connection of a job start, end, deletion, or other activity. While this would seem to have little to do with an output connector, this feature has been requested by Jack Krupansky as a potential way of deciding when to tell Solr to commit documents, rather than leave it up to Solr's configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About name change
Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: About name change
I, too like it. There's a problem though: http://en.wikipedia.org/wiki/Manifold_System Other similar possibilities include Multiplex, or maybe we get somewhere by using ManifoldCF? Or maybe Apache Manifold is different enough from Manifold System to be distinguishable? FWIW, Multiplex is also used, but it doesn't seem to be very significant: http://mc3030.heim1.de/english.php Karl On Tue, Aug 31, 2010 at 6:46 AM, Grant Ingersoll gsing...@apache.orgwrote: Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: About name change -- Macon
How about Macon... from Mac[hinery] + con[nection]. A small city, also a dirigible airship. -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 31, 2010 6:46 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: About name change -- Macon
I don't find any obvious software uses of the name. I don't find it terribly descriptive though - multiplex/manifold wins in my opinion. Acromantula is also available and is more descriptive: http://harrypotter.wikia.com/wiki/Acromantula (if you don't mind the HP references. ;-) ) Karl On Tue, Aug 31, 2010 at 7:52 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: How about Macon... from Mac[hinery] + con[nection]. A small city, also a dirigible airship. -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 31, 2010 6:46 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Re: About name change -- Acromantula
Brand names are better when they are less purely descriptive or simply indirectly descriptive. I'm okay with Acromantula if people want it, especially since it seems to adhere to all the Apache guidelines, but since I am unable to pronounce it, I would be able to promote it via word of mouth! Or, might J. K. Rowling sue us for stealing her work? -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Tuesday, August 31, 2010 8:01 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change -- Macon I don't find any obvious software uses of the name. I don't find it terribly descriptive though - multiplex/manifold wins in my opinion. Acromantula is also available and is more descriptive: http://harrypotter.wikia.com/wiki/Acromantula (if you don't mind the HP references. ;-) ) Karl On Tue, Aug 31, 2010 at 7:52 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: How about Macon... from Mac[hinery] + con[nection]. A small city, also a dirigible airship. -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 31, 2010 6:46 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
Name nominations CLOSING at 5 PM EDT today
Gotta do it. We've got to have a vote among the connectors developers, and before that we need all the name candidates on the slate. At 5 PM I intend to present the feasible candidates (I will include the current Apache Connectors Framework), and ask everyone to rank them in order of preference. Any objections? Karl
Name nominations CLOSING at 5 PM EDT today
Gotta do it. We've got to have a vote among the connectors developers, and before that we need all the name candidates on the slate. At 5 PM I intend to present the feasible candidates (I will include the current Apache Connectors Framework), and ask everyone to rank them in order of preference. Any objections? Karl
[jira] Commented: (CONNECTORS-41) Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc.
[ https://issues.apache.org/jira/browse/CONNECTORS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904611#action_12904611 ] Karl Wright commented on CONNECTORS-41: --- Does it makes no sense to create an entirely new kind of connector just for notifications of this sort? So when you create a job you select THREE different kinds of connection (repository, output, and notification)? That seems like supreme overkill to me, and I can well argue that this kind of notification really is only useful to an output connection in any case. Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc. --- Key: CONNECTORS-41 URL: https://issues.apache.org/jira/browse/CONNECTORS-41 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Karl Wright Priority: Minor Currently there is no logic that informs an output connection of a job start, end, deletion, or other activity. While this would seem to have little to do with an output connector, this feature has been requested by Jack Krupansky as a potential way of deciding when to tell Solr to commit documents, rather than leave it up to Solr's configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-41) Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc.
[ https://issues.apache.org/jira/browse/CONNECTORS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904622#action_12904622 ] Karl Wright commented on CONNECTORS-41: --- I think we're discussing two entirely distinct features here. Feature 1: Let the output connector know that a job is finished, so that it can flush whatever internal buffering etc. it has been doing (e.g. tell solr to commit). Feature 2: Provide some general way of monitoring the progress of jobs etc. Feature 2 is already met by the API, in my opinion. It's a polling-style fulfillment of the requirement, but it does exist. There doesn't seem to me to yet be a requirement that a notification-style API be provided also, despite the stated use case. Feature 1 is what I consider to be the use case for this current ticket. Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc. --- Key: CONNECTORS-41 URL: https://issues.apache.org/jira/browse/CONNECTORS-41 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Karl Wright Priority: Minor Currently there is no logic that informs an output connection of a job start, end, deletion, or other activity. While this would seem to have little to do with an output connector, this feature has been requested by Jack Krupansky as a potential way of deciding when to tell Solr to commit documents, rather than leave it up to Solr's configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About name change -- Lucon, Lukon
Omnivore, perhaps? A little more findable... Of course, now the humorist in me tries to extend this in obviously wrong directions, like Apache Yardsale and Apache VacuumCleaner. ;-) Tying to Lucene seems like not quite the right idea, in my view, but we can vote on it. Karl On Tue, Aug 31, 2010 at 10:33 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: To increase findability, how about Lucon or Lukon - Lu[cene] + con[nector] or k for Karl. -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 31, 2010 10:25 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change -- Acromantula Maybe we should just ask Doug Cutting's kid to come up with a name ;-) FWIW, we should also think about names that are findable. Omni is likely to be buried in any search engine Of course, it's easy to be the critic, much harder to come up with a good suggestion. On Aug 31, 2010, at 8:11 AM, Karl Wright wrote: Ackromantyoola. I think JK got the name from somewhere else anyhow, so there's prior art involved. ;-) Karl On Tue, Aug 31, 2010 at 8:08 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: Brand names are better when they are less purely descriptive or simply indirectly descriptive. I'm okay with Acromantula if people want it, especially since it seems to adhere to all the Apache guidelines, but since I am unable to pronounce it, I would be able to promote it via word of mouth! Or, might J. K. Rowling sue us for stealing her work? -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Tuesday, August 31, 2010 8:01 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change -- Macon I don't find any obvious software uses of the name. I don't find it terribly descriptive though - multiplex/manifold wins in my opinion. Acromantula is also available and is more descriptive: http://harrypotter.wikia.com/wiki/Acromantula (if you don't mind the HP references. ;-) ) Karl On Tue, Aug 31, 2010 at 7:52 AM, Jack Krupansky jack.krupan...@lucidimagination.com wrote: How about Macon... from Mac[hinery] + con[nection]. A small city, also a dirigible airship. -- Jack Krupansky -- From: Grant Ingersoll gsing...@apache.org Sent: Tuesday, August 31, 2010 6:46 AM To: connectors-dev@incubator.apache.org Subject: Re: About name change Apache Manifold is growing on me. And/or Apache Manifold CF or Apache Manifold Conn. Framework. Has a nice short name, easy to pronounce, doesn't require funky acronyms and from Webster's: Machinery . a chamber having several outlets through which a liquid or gas is distributed or gathered. -- http://dictionary.reference.com/browse/Manifold Paraphrased, it's a a chamber having several outlets through which bits are gathered and distributed. -Grant On Aug 30, 2010, at 5:57 PM, Mark Miller wrote: On 8/30/10 5:20 PM, Karl Wright wrote: I'm not going to go head-to-head with you trying to split hairs. ;-) Can we agree that something like ContentCF is a possibility under your guidelines? (I'm not proposing that, I'm just trying to open the field up a bit.) Karl From my end, most of that was off topic haggling - I'm not saying it should be one way or other per seh. I personally see the benefit of having a good unique word in the name of the project - and of trying to follow the guidelines / feel of previous projects. I'd be perfectly fine with something like Apache Manifold Connector Framework. But push come to shove I wouldn't even vote against keeping things as is with the Apache Connector Framework. - Mark -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8 -- Grant Ingersoll http://lucenerevolution.org Apache Lucene/Solr Conference, Boston Oct 7-8
[jira] Assigned: (CONNECTORS-41) Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc.
[ https://issues.apache.org/jira/browse/CONNECTORS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-41: - Assignee: Karl Wright Add hooks to output connectors for receiving event notifications, specifically job start, job end, etc. --- Key: CONNECTORS-41 URL: https://issues.apache.org/jira/browse/CONNECTORS-41 Project: Apache Connectors Framework Issue Type: Improvement Components: Framework core Reporter: Karl Wright Assignee: Karl Wright Priority: Minor Currently there is no logic that informs an output connection of a job start, end, deletion, or other activity. While this would seem to have little to do with an output connector, this feature has been requested by Jack Krupansky as a potential way of deciding when to tell Solr to commit documents, rather than leave it up to Solr's configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-57) Solr output connector option to commit at end of job, by default
[ https://issues.apache.org/jira/browse/CONNECTORS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904736#action_12904736 ] Karl Wright commented on CONNECTORS-57: --- I added unconditional commit support to the Solr connector as part of ticket CONNECTORS-41. The ability to turn it off and on cannot be done per job based on that implementation, but could readily be specified per Solr connection. This makes more sense to me anyway, since what will control whether you want this feature on or not is your solr configuration, and that's not going to change per job. Solr output connector option to commit at end of job, by default Key: CONNECTORS-57 URL: https://issues.apache.org/jira/browse/CONNECTORS-57 Project: Apache Connectors Framework Issue Type: Sub-task Components: Lucene/SOLR connector Reporter: Jack Krupansky By default, Solr will eventually commit documents that have been submitted to the Solr Cell interface, but the time lag can confuse and annoy people. Although commit strategy is a difficult issue in general, an option in LCF to automatically commit at the end of a job, by default, would eliminate a lot of potential confusion and generally be close to what the user needs. The desired feature is that there be an option to commit for each job that uses the Solr output connector. This option would default to on (or a different setting based on some global configuration setting), but the user may turn it off if commit is only desired upon completion of some jobs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-57) Solr output connector option to commit at end of job, by default
[ https://issues.apache.org/jira/browse/CONNECTORS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904746#action_12904746 ] Jack Krupansky commented on CONNECTORS-57: -- This looks fine so far and should work for me. If I understand the code, the Connector.noteJobComplete method is called when the job completes or is aborted and the SolrConnector.noteJobComplete implementation method unconditionally does a commit. That's fine my my use case, but we probably still want a connection option to disable that commit if the user has some other commit strategy in mind. Solr output connector option to commit at end of job, by default Key: CONNECTORS-57 URL: https://issues.apache.org/jira/browse/CONNECTORS-57 Project: Apache Connectors Framework Issue Type: Sub-task Components: Lucene/SOLR connector Reporter: Jack Krupansky By default, Solr will eventually commit documents that have been submitted to the Solr Cell interface, but the time lag can confuse and annoy people. Although commit strategy is a difficult issue in general, an option in LCF to automatically commit at the end of a job, by default, would eliminate a lot of potential confusion and generally be close to what the user needs. The desired feature is that there be an option to commit for each job that uses the Solr output connector. This option would default to on (or a different setting based on some global configuration setting), but the user may turn it off if commit is only desired upon completion of some jobs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Pick your preferred name
I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl
Re: [VOTE] Pick your preferred name
1. Apache Yukon 2. Apache Macon 3. Apache Lukon -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Tuesday, August 31, 2010 6:44 PM To: connectors-dev connectors-dev@incubator.apache.org Subject: [VOTE] Pick your preferred name I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl
Re: [VOTE] Pick your preferred name
My preferences: Apache Connectors Framework Apache Manifold Apache Acromantula Karl On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl
Re: [VOTE] Pick your preferred name
Apache Manifold Apache Connectors Framework Apache Yukon - mark On 8/31/10 6:54 PM, Karl Wright wrote: My preferences: Apache Connectors Framework Apache Manifold Apache Acromantula Karl On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl
Re: [VOTE] Pick your preferred name
Don't know if this is an open vote... but if it is: Apache Connectors Framework Apache Yukon Apache Manifold -- Thanks, Matt Weber 3:58 PM, Mark Miller markrmil...@gmail.com wrote: Apache Manifold Apache Connectors Framework Apache Yukon - mark On 8/31/10 6:54 PM, Karl Wright wrote: My preferences: Apache Connectors Framework Apache Manifold Apache Acromantula Karl On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl -- Thanks, Matt Weber
Re: [VOTE] Pick your preferred name
Well, you've made your feelings clear. ;-) Karl On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir rcm...@gmail.com wrote: Apache Connectors Framework Apache Connectors Framework Apache Connectors Framework (sorry) On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl -- Robert Muir rcm...@gmail.com
Re: [VOTE] Pick your preferred name
you can ignore my vote really :) but i was thinking from a practical perspective, this one involves the least code changes. plus, with existing projects named things like apache DB and apache http server, i don't understand the fuss. On Tue, Aug 31, 2010 at 8:03 PM, Karl Wright daddy...@gmail.com wrote: Well, you've made your feelings clear. ;-) Karl On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir rcm...@gmail.com wrote: Apache Connectors Framework Apache Connectors Framework Apache Connectors Framework (sorry) On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl -- Robert Muir rcm...@gmail.com -- Robert Muir rcm...@gmail.com
Re: [VOTE] Pick your preferred name
I think this vote will conclusively demonstrate the community position to the solons at incubator. They can choose to ignore the vote, of course, but they won't be able to say we didn't consider alternatives. ;-) Karl On Tue, Aug 31, 2010 at 8:16 PM, Mark Miller markrmil...@gmail.com wrote: I think its pretty clear that unless the lords of the incubator *force* us to do otherwise, we should just leave it as Apache Connectors Framework. The vote is going to end up reflecting that is my bet anyway. I havn't seen anyone that's actually involved (if you can say anyone beyond karl is really involved anyway) is really dying for a change. - Mark On 8/31/10 8:07 PM, Robert Muir wrote: you can ignore my vote really :) but i was thinking from a practical perspective, this one involves the least code changes. plus, with existing projects named things like apache DB and apache http server, i don't understand the fuss. On Tue, Aug 31, 2010 at 8:03 PM, Karl Wright daddy...@gmail.com wrote: Well, you've made your feelings clear. ;-) Karl On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir rcm...@gmail.com wrote: Apache Connectors Framework Apache Connectors Framework Apache Connectors Framework (sorry) On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl -- Robert Muir rcm...@gmail.com
