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 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 wrote: > > > >> Well, you've made your feelings clear. ;-) > >> Karl > >> > >> On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir wrote: > >> > >>> Apache Connectors Framework > >>> Apache Connectors Framework > >>> Apache Connectors Framework > >>> > >>> (sorry) > >>> > >>> On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright > 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
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 wrote: > >> Well, you've made your feelings clear. ;-) >> Karl >> >> On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir wrote: >> >>> Apache Connectors Framework >>> Apache Connectors Framework >>> Apache Connectors Framework >>> >>> (sorry) >>> >>> On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright 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 wrote: > Well, you've made your feelings clear. ;-) > Karl > > On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir wrote: > > > Apache Connectors Framework > > Apache Connectors Framework > > Apache Connectors Framework > > > > (sorry) > > > > On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright 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
Well, you've made your feelings clear. ;-) Karl On Tue, Aug 31, 2010 at 7:58 PM, Robert Muir wrote: > Apache Connectors Framework > Apache Connectors Framework > Apache Connectors Framework > > (sorry) > > On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright 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
Apache Connectors Framework Apache Connectors Framework Apache Connectors Framework (sorry) On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright 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
On 8/31/10 7:09 PM, Matt Weber wrote: > Don't know if this is an open vote... but if it is: > > Apache Connectors Framework > Apache Yukon > Apache Manifold > > The more input the merrier!
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 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 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
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 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
My preferences: Apache Connectors Framework Apache Manifold Apache Acromantula Karl On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright 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
1. Apache Yukon 2. Apache Macon 3. Apache Lukon -- Jack Krupansky -- From: "Karl Wright" Sent: Tuesday, August 31, 2010 6:44 PM To: "connectors-dev" 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: About name change
Huh. My vote post didn't make it either. The connectors-dev list must be holding my posts for moderation or something. So I'll post it in-thread as well, and hope that somebody fixes my email soon. 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 On Tue, Aug 31, 2010 at 10:39 AM, Karl Wright wrote: > I hope to call a vote tonight, but my posting about that never made it > through for some reason. (I posted the same thing twice, too!). Anyhow, > I'll include all of these in the list of candidates. It would be good to > find out in advance if Apache Manifold is a possibility, though. That would > be my first choice at the moment. > > Karl > > > On Tue, Aug 31, 2010 at 10:12 AM, Grant Ingersoll wrote: > >> >> On Aug 31, 2010, at 7:45 AM, Karl Wright wrote: >> >> > 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? >> >> I think ManifoldCF is distinct enough, I think, but we may need a outside >> ruling on that. >> >> > >> > FWIW, Multiplex is also used, but it doesn't seem to be very >> significant: >> >> This makes me think of movie theaters... >> >> > >> > http://mc3030.heim1.de/english.php >> > >> > >> > Karl >> > >> > On Tue, Aug 31, 2010 at 6:46 AM, Grant Ingersoll > >wrote: >> > >> >> 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 >> >> >
[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
[jira] Resolved: (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:all-tabpanel ] Karl Wright resolved CONNECTORS-57. --- Fix Version/s: LCF Release 0.5 Resolution: Fixed Checked in a new tab. r991374. > 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 > Fix For: LCF Release 0.5 > > > 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-62) Document the LCF API
[ https://issues.apache.org/jira/browse/CONNECTORS-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904768#action_12904768 ] Jack Krupansky commented on CONNECTORS-62: -- Just wanted to update the link to the doc after the LCF/ACF name change for people who search for this issue: https://cwiki.apache.org/confluence/display/CONNECTORS/Programmatic+Operation+of+ACF > Document the LCF API > > > Key: CONNECTORS-62 > URL: https://issues.apache.org/jira/browse/CONNECTORS-62 > Project: Apache Connectors Framework > Issue Type: Improvement > Components: Documentation >Reporter: Karl Wright >Assignee: Karl Wright > > Not only does the LCF API itself need documentation, but so do all the > connector configuration/specification objects, now that they are exposed. > This should probably become part of the developer documentation on the main > LCF website. -- 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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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] Resolved: (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 resolved CONNECTORS-41. --- Fix Version/s: LCF Release 0.5 Resolution: Fixed Fix checked in, r991295. > 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 > Fix For: LCF Release 0.5 > > > 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] 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.
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" > Sent: Tuesday, August 31, 2010 10:25 AM > To: > 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" Sent: Tuesday, August 31, 2010 8:01 AM To: 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" >> Sent: Tuesday, August 31, 2010 6:46 AM >> To: >> 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 >> >>
Re: About name change
I hope to call a vote tonight, but my posting about that never made it through for some reason. (I posted the same thing twice, too!). Anyhow, I'll include all of these in the list of candidates. It would be good to find out in advance if Apache Manifold is a possibility, though. That would be my first choice at the moment. Karl On Tue, Aug 31, 2010 at 10:12 AM, Grant Ingersoll wrote: > > On Aug 31, 2010, at 7:45 AM, Karl Wright wrote: > > > 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? > > I think ManifoldCF is distinct enough, I think, but we may need a outside > ruling on that. > > > > > FWIW, Multiplex is also used, but it doesn't seem to be very significant: > > This makes me think of movie theaters... > > > > > http://mc3030.heim1.de/english.php > > > > > > Karl > > > > On Tue, Aug 31, 2010 at 6:46 AM, Grant Ingersoll >wrote: > > > >> 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 > >
Re: About name change -- Lucon, Lukon
To increase findability, how about Lucon or Lukon - Lu[cene] + con[nector] or "k" for Karl. -- Jack Krupansky -- From: "Grant Ingersoll" Sent: Tuesday, August 31, 2010 10:25 AM To: 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" Sent: Tuesday, August 31, 2010 8:01 AM To: 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" Sent: Tuesday, August 31, 2010 6:46 AM To: 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
Re: About name change
Technically, the official name would be "Apache Manifold" anyway. The "Apache" always gets prefixed. Even Yukon may be okay since it would actually be "Apache Yukon". In short, we don't need to propose "Apache" as part of what we vote on since that will automatically get added, I think. -- Jack Krupansky -- From: "Grant Ingersoll" Sent: Tuesday, August 31, 2010 10:12 AM To: Subject: Re: About name change On Aug 31, 2010, at 7:45 AM, Karl Wright wrote: 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? I think ManifoldCF is distinct enough, I think, but we may need a outside ruling on that. FWIW, Multiplex is also used, but it doesn't seem to be very significant: This makes me think of movie theaters... http://mc3030.heim1.de/english.php Karl On Tue, Aug 31, 2010 at 6:46 AM, Grant Ingersoll wrote: 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
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" >> Sent: Tuesday, August 31, 2010 8:01 AM >> To: >> 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" Sent: Tuesday, August 31, 2010 6:46 AM To: 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
Re: About name change -- Macon
On Aug 31, 2010, at 8:01 AM, Karl Wright wrote: > 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 I don't personally like it. There are enough HP software names out there, IMO and I think it is non-obvious how to pronounce it. > > (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" >> Sent: Tuesday, August 31, 2010 6:46 AM >> To: >> 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
Re: About name change
On Aug 31, 2010, at 7:45 AM, Karl Wright wrote: > 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? I think ManifoldCF is distinct enough, I think, but we may need a outside ruling on that. > > FWIW, Multiplex is also used, but it doesn't seem to be very significant: This makes me think of movie theaters... > > http://mc3030.heim1.de/english.php > > > Karl > > On Tue, Aug 31, 2010 at 6:46 AM, Grant Ingersoll wrote: > >> 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] 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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=12904618#action_12904618 ] Jack Krupansky commented on CONNECTORS-41: -- The notification is certainly "associated" with the output connection... or is it really associated with the job? Originally, my thinking had been that the notification URL would be specified as part of the output connection, but maybe it is an output-specific parameter that gets specified for the job. It could be either. OTOH, maybe a "notification connector" makes more sense and is more general rather than just something to use for Solr. Also, that might provide the way to implement an optional commit for Solr, as a simple notification connection, so that ACF core itself doesn't know or care about Solr or commits or any of that. I think the concept of a notification connector makes sense, but is not essential for release 0.1 or 0.5. I'm open to suggestions. We can do it real simple as a parameter for the Solr output connector or the job, or we could be more general. Tough call. If you feel up to doing the more general feature, fine, but the simple notification URL feature is all that is essential. Also, to be clear about the use case, it is not just Solr commit, but some external app might just want to notify a user that their job has finished and to do whatever other (beyond Solr commit) processing may be needed upon job completion. > 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-tabpanel&focusedCommentId=12904614#action_12904614 ] Karl Wright commented on CONNECTORS-41: --- I also claim that even if a wholly-as-yet-to-be-cooked-up external process is notified, you will have (a) the possibility of error, and (b) the probability of delay, because you are going to want this behavior to be synchronous. So all my original reasoning still applies. I would furthermore argue that we really want the Solr output connector to work against the existing Solr artifact. So if you have something special in mind, please either offer it as a patch to Solr, or write your own dedicated output connector. > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=12904610#action_12904610 ] Jack Krupansky commented on CONNECTORS-41: -- To be clear about the use case, the notification is not to an output connector or output connection per se, but to an external process that is trying to monitor the job status. Kind of a reverse API. The URL that job status notifications should be sent to might be in the same process as Solr or another process that is monitoring Solr. Further, this feature should be of value for any type of output connector, although Solr is my current main interest. > 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.
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
Re: About name change -- Acromantula
"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" > Sent: Tuesday, August 31, 2010 8:01 AM > To: > 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" >>> Sent: Tuesday, August 31, 2010 6:46 AM >>> To: >>> 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
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" Sent: Tuesday, August 31, 2010 8:01 AM To: 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" Sent: Tuesday, August 31, 2010 6:46 AM To: 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
Simon suggests "Apache Omni", which I also like, and which does not appear to be common in software packages (although there is a company called the "Omni Group", apparently). Karl On Tue, Aug 31, 2010 at 7:53 AM, Karl Wright wrote: > Hah. If I'd scrolled past the German, I would have realized that the > "Multiplex" this refers to is in fact a piece of hardware, so I think we'd > be OK with this one. > > Karl > > > On Tue, Aug 31, 2010 at 7:45 AM, Karl Wright wrote: > >> 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 wrote: >> >>> 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" > Sent: Tuesday, August 31, 2010 6:46 AM > To: > 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
Hah. If I'd scrolled past the German, I would have realized that the "Multiplex" this refers to is in fact a piece of hardware, so I think we'd be OK with this one. Karl On Tue, Aug 31, 2010 at 7:45 AM, Karl Wright wrote: > 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 wrote: > >> 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" Sent: Tuesday, August 31, 2010 6:46 AM To: 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
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 wrote: > 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
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
[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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=12904558#action_12904558 ] Karl Wright commented on CONNECTORS-92: --- I've thought about start.jar some more. I think it is essential that maven produce a jar that is functionally identical to the start.jar produced by the ant build, including the relative paths for all the classpath entries. Maven may be unable to directly produce the modules/dist/example output directory in the same way, but that's a different problem. I don't think there's going to be room in the world for two entirely distinct ways of running the example, and I want to avoid that - for documentation reasons, if for none other. The other reason for wanting the example setup to be identical is because the example organizational assumptions are partly baked into the jetty-runner code at this time. Those could in part be passed in as command-line arguments, but that would make running the example considerably harder, so I'd like to avoid that if possible. > 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.
