[jira] Commented: (CONNECTORS-116) Possibly remove memex connector depending upon legal resolution
[ https://issues.apache.org/jira/browse/CONNECTORS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920542#action_12920542 ] Mark Miller commented on CONNECTORS-116: Indeed - my impression is that we are all happy to see this code be pulled if that's what the original contributors want (or what they are legally bound to want) - we just think that process should be public before the code is silently taken out back and shot ;) > Possibly remove memex connector depending upon legal resolution > --- > > Key: CONNECTORS-116 > URL: https://issues.apache.org/jira/browse/CONNECTORS-116 > Project: ManifoldCF > Issue Type: Task > Components: Memex connector >Reporter: Robert Muir >Assignee: Robert Muir > > Apparently there is an IP problem with the memex connector code. > Depending upon what apache legal says, we will take any action under this > issue publicly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1021533 - in /incubator/lcf/trunk: modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/ tests/memex-testing-package/org/apache/manifoldcf/c
It's kind of odd to just nuke a bunch of code without any public discussion? The content is still in svn and or has been distributed...what is the hurry in ramming through this svn remove? This seems very unusual and not apache like... On Tue, Oct 12, 2010 at 11:58 AM, Karl Wright wrote: > There will be a letter sent out shortly. The text is currently be > reviewed by various legal entities. > Karl > > On Tue, Oct 12, 2010 at 11:49 AM, Robert Muir wrote: > > I'm a little confused... I didn't see anything on the mailing list. We > > deleted a connector because a company asked? > > > > On Mon, Oct 11, 2010 at 6:07 PM, wrote: > >> Author: kwright > >> Date: Mon Oct 11 22:07:11 2010 > >> New Revision: 1021533 > >> > >> URL: http://svn.apache.org/viewvc?rev=1021533&view=rev > >> Log: > >> Remove Memex Connector files that interact with Memex, as per > MetaCarta's request. > >> > >> Removed: > >> > > incubator/lcf/trunk/modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/LogicalServer.java > >> > > incubator/lcf/trunk/modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/ManifoldCFMemexConnection.java > >> > > incubator/lcf/trunk/modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/MemexAuthority.java > >> > > incubator/lcf/trunk/modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/MemexConnector.java > >> > > incubator/lcf/trunk/modules/connectors/memex/connector/src/main/java/org/apache/manifoldcf/crawler/connectors/memex/MemexEntity.java > >> > > incubator/lcf/trunk/tests/memex-testing-package/org/apache/manifoldcf/crawler/connectors/memex/MemexSupport.java > >> > >> > > > -- - Mark http://www.lucidimagination.com
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
>>>> >>>>>> Karl >>>>>> >>>>>> On Wed, Sep 29, 2010 at 11:01 AM, Upayavira wrote: >>>>>>> >>>>>>> Some while back I suggested manifolio. But that breaches the four >>>>>>> syllable rule :-) >>>>>>> >>>>>>> How about Manifole? >>>>>>> >>>>>>> I'd say rather than bursting into votes, keep the discussion >>>>>>> going, I >>>>>>> suspect you'll know when you've got enough of the community >>>>>>> behind you, >>>>>>> and when it is then worth wrapping the whole thing up with a vote >>>>>>> - at >>>>>>> which point the vote is a mere formality. >>>>>>> >>>>>>> Worth giving it the effort now, see this recent post [1] - a name is >>>>>>> going to stay with us all for a long time! >>>>>>> >>>>>>> Upayavira >>>>>>> >>>>>>> [1] http://enthusiasm.cozy.org/archives/2010/09/first-time-right >>>>>>> >>>>>>> On Tue, 2010-09-28 at 20:08 -0400, Karl Wright wrote: >>>>>>>> >>>>>>>> Actually, an abbreviation of "AMCF" is not bad either kinda >>>>>>>> like >>>>>>>> that myself. But I'm still not sure I like any of the book title >>>>>>>> choices I've offered myself here. >>>>>>>> >>>>>>>> Do we dare use "Manifold Connectors Framework in Action"? and >>>>>>>> describe AMCF as "Manifold Connectors Framework" at times? >>>>>>>> >>>>>>>> Karl >>>>>>>> >>>>>>>> On Tue, Sep 28, 2010 at 8:04 PM, Karl Wright >>>>>>>> wrote: >>>>>>>> > If this is adopted, I'm thinking we could use it in the >>>>>>>> following > > >>>>>>>> > ways: >>>>>>>> > >>>>>>>> > Abbreviation: "MCF" >>>>>>>> > Short name: "ManifoldCF" >>>>>>>> > Qualified short name: "Apache ManifoldCF" >>>>>>>> > Fully qualified and unabbreviated name: "the Apache Manifold >>>>>>>> > Connectors Framework" >>>>>>>> > >>>>>>>> > I'm not quite sure what the world will think of that last >>>>>>>> usage, > >>>>>>>> > since >>>>>>>> > it does not contain the trademark. Then again, neither does the >>>>>>>> > abbreviation. But I'm not sure I'd dare make the book title be >>>>>>>> > "Apache Manifold Connectors Framework in Action". It would > >>>>>>>> probably >>>>>>>> > need to be "Apache ManifoldCF in Action", or just "ManifoldCF in >>>>>>>> > Action". >>>>>>>> > >>>>>>>> > Grant, you wrote a book. What do you think? Which title >>>>>>>> should > be >>>>>>>> > > > >>>>>>>> > used? >>>>>>>> > >>>>>>>> > Karl >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > On Tue, Sep 28, 2010 at 7:30 PM, Jack Krupansky >>>>>>>> > wrote: >>>>>>>> >> -1 for me. Standing alone it's an okay name, but trying to >> >>>>>>>> actually >>>>>>>> >> >> use it >>>>>>>> >> is a pain (and we might as well call it MCF). But I'll >>>>>>>> certainly >> go >>>>>>>> >> >> along >>>>>>>> >> with the majority. >>>>>>>> >> >>>>>>>> >> -- Jack Krupansky >>>>>>>> >> >>>>>>>> >> -- >>>>>>>> >> From: &qu
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
On 9/28/10 6:40 PM, Karl Wright wrote: > Vote +1 to rename Apache Connectors Framework to Apache ManifoldCF. > Vote -1 to keep the project name of Connectors Framework, or to retain > Connex, if that wins its vote. > > This vote also expires end of day on Friday. > > Note: "Manifold" is a trademark for a GIS software product. However, > I agree with Grant that ManifoldCF appearing under the Apache label > should be safe to be used. But you should recognize that this vote is > not merely a referendum on the name itself, but also on the > suitability of the name in a legal context. > > Karl +1 - Mark
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
I'm with you Karl. +1 - Mark On 9/29/10 11:08 AM, Karl Wright wrote: > May I point out that we've been discussing this issue for over two months now? > > We just went through a process of gathering names, came up with some > 35 candidates, and voted to rank them. This process just ended, our > best candidate turned out to not have been submitted properly, but we > still have some 15 other names that people legitimately selected, > ranked in order. > > Prior to that, we did a previous round where we did EXACTLY the same > thing, and Apache Connectors Framework was the winning selection, > followed by ManifoldCF. It sounds now like you are looking for yet a > third round? Unless you claim that the candidate list was simply not > broad enough, I can see no hope of gain by doing that. > > Karl > > On Wed, Sep 29, 2010 at 11:01 AM, Upayavira wrote: >> Some while back I suggested manifolio. But that breaches the four >> syllable rule :-) >> >> How about Manifole? >> >> I'd say rather than bursting into votes, keep the discussion going, I >> suspect you'll know when you've got enough of the community behind you, >> and when it is then worth wrapping the whole thing up with a vote - at >> which point the vote is a mere formality. >> >> Worth giving it the effort now, see this recent post [1] - a name is >> going to stay with us all for a long time! >> >> Upayavira >> >> [1] http://enthusiasm.cozy.org/archives/2010/09/first-time-right >> >> On Tue, 2010-09-28 at 20:08 -0400, Karl Wright wrote: >>> Actually, an abbreviation of "AMCF" is not bad either kinda like >>> that myself. But I'm still not sure I like any of the book title >>> choices I've offered myself here. >>> >>> Do we dare use "Manifold Connectors Framework in Action"? and >>> describe AMCF as "Manifold Connectors Framework" at times? >>> >>> Karl >>> >>> On Tue, Sep 28, 2010 at 8:04 PM, Karl Wright wrote: >>>> If this is adopted, I'm thinking we could use it in the following ways: >>>> >>>> Abbreviation: "MCF" >>>> Short name: "ManifoldCF" >>>> Qualified short name: "Apache ManifoldCF" >>>> Fully qualified and unabbreviated name: "the Apache Manifold >>>> Connectors Framework" >>>> >>>> I'm not quite sure what the world will think of that last usage, since >>>> it does not contain the trademark. Then again, neither does the >>>> abbreviation. But I'm not sure I'd dare make the book title be >>>> "Apache Manifold Connectors Framework in Action". It would probably >>>> need to be "Apache ManifoldCF in Action", or just "ManifoldCF in >>>> Action". >>>> >>>> Grant, you wrote a book. What do you think? Which title should be used? >>>> >>>> Karl >>>> >>>> >>>> >>>> On Tue, Sep 28, 2010 at 7:30 PM, Jack Krupansky >>>> wrote: >>>>> -1 for me. Standing alone it's an okay name, but trying to actually use it >>>>> is a pain (and we might as well call it MCF). But I'll certainly go along >>>>> with the majority. >>>>> >>>>> -- Jack Krupansky >>>>> >>>>> -- >>>>> From: "Karl Wright" >>>>> Sent: Tuesday, September 28, 2010 7:25 PM >>>>> To: >>>>> Subject: Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF >>>>> >>>>>> Ok, I just want an up-or-down vote on ManifoldCF at this point. +1 from >>>>>> me. >>>>>> >>>>>> Karl >>>>>> >>>>>> On Tue, Sep 28, 2010 at 7:22 PM, Mark Miller >>>>>> wrote: >>>>>>> >>>>>>> On 9/28/10 7:10 PM, Jack Krupansky wrote: >>>>>>>> >>>>>>>> Fair enough. I could live with any of the other choices, but having >>>>>>>> this >>>>>>>> "CF" suffix really messes a lot of stuff up and is less practical than >>>>>>>> any of the other names. Basically, it means we may end up having to use >>>>>>>> "MCF" as the shorthand name. >>>>>>>> >>>>>
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
On 9/28/10 7:10 PM, Jack Krupansky wrote: > Fair enough. I could live with any of the other choices, but having this > "CF" suffix really messes a lot of stuff up and is less practical than > any of the other names. Basically, it means we may end up having to use > "MCF" as the shorthand name. > > Wait... stop the presses... I just realized that "ManifoldCF" violates > selection rule #5: > > (5) No more than 4 syllables > > Man-I-fold-C-F (or is in Ma-ni-fold-C-F.) > > That's five syllables. ManifoldCF was already in the running. And its obvious that having too many syllables is not a problem - it was the second most voted name - for the *second* time at least (who can track all these votes). > > And, technically, I would say that it at least half violates the spirit > of rule #1: > > (1) It's a single word > > It is a single word plus this extra "CF" acronym thing. That's a stretch that the rational part of my brain is going to ignore. This is no argument. > > So, next candidate on the list was... Manicon, 19 > > Unless it has legal problems, it fits our requirements. Okay, lets vote again. For some reason ManifoldCF will stop topping the list why? Everyone will come to their senses? Some of us are so sick of this name thing we won't vote, and if your lucky those will be the ManifoldCF supporters? I mean come on... > > -- Jack Krupansky > > -- > From: "Karl Wright" > Sent: Tuesday, September 28, 2010 6:52 PM > To: > Subject: Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF > >> Jack, >> >> That's one of the main purposes of having everyone list choices by >> priority. If one doesn't work, there are others you can use. >> >> I don't want to open that vote again unless the community decides that >> the list of candidate names was simply not rich enough to furnish a >> good choice. >> >> Karl >> >> >> On Tue, Sep 28, 2010 at 6:49 PM, Jack Krupansky >> wrote: >>> Or Nocon or Noman. >>> >>> I know people are tired of voting, but I think we should really >>> re-vote for >>> the revised candidate list with Connex removed. >>> >>> -- Jack Krupansky >>> >>> -- >>> From: "Mark Miller" >>> Sent: Tuesday, September 28, 2010 6:43 PM >>> To: >>> Subject: Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF >>> >>>> hmmm...I think I'm all voted out. Can we just call it nothing? >>>> >>>> On 9/28/10 6:40 PM, Karl Wright wrote: >>>>> >>>>> Vote +1 to rename Apache Connectors Framework to Apache ManifoldCF. >>>>> Vote -1 to keep the project name of Connectors Framework, or to retain >>>>> Connex, if that wins its vote. >>>>> >>>>> This vote also expires end of day on Friday. >>>>> >>>>> Note: "Manifold" is a trademark for a GIS software product. However, >>>>> I agree with Grant that ManifoldCF appearing under the Apache label >>>>> should be safe to be used. But you should recognize that this vote is >>>>> not merely a referendum on the name itself, but also on the >>>>> suitability of the name in a legal context. >>>>> >>>>> Karl >>>> >>>
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
+1 on just moving down the list. We put our votes in order, so this makes perfect sense to me. Why revote? Next candidate in the list! - Mark On 9/28/10 6:52 PM, Karl Wright wrote: > Jack, > > That's one of the main purposes of having everyone list choices by > priority. If one doesn't work, there are others you can use. > > I don't want to open that vote again unless the community decides that > the list of candidate names was simply not rich enough to furnish a > good choice. > > Karl > > > On Tue, Sep 28, 2010 at 6:49 PM, Jack Krupansky > wrote: >> Or Nocon or Noman. >> >> I know people are tired of voting, but I think we should really re-vote for >> the revised candidate list with Connex removed. >> >> -- Jack Krupansky >> >> -- >> From: "Mark Miller" >> Sent: Tuesday, September 28, 2010 6:43 PM >> To: >> Subject: Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF >> >>> hmmm...I think I'm all voted out. Can we just call it nothing? >>> >>> On 9/28/10 6:40 PM, Karl Wright wrote: >>>> >>>> Vote +1 to rename Apache Connectors Framework to Apache ManifoldCF. >>>> Vote -1 to keep the project name of Connectors Framework, or to retain >>>> Connex, if that wins its vote. >>>> >>>> This vote also expires end of day on Friday. >>>> >>>> Note: "Manifold" is a trademark for a GIS software product. However, >>>> I agree with Grant that ManifoldCF appearing under the Apache label >>>> should be safe to be used. But you should recognize that this vote is >>>> not merely a referendum on the name itself, but also on the >>>> suitability of the name in a legal context. >>>> >>>> Karl >>> >>
Re: [VOTE] Rename Apache Connectors Framework to ManifoldCF
hmmm...I think I'm all voted out. Can we just call it nothing? On 9/28/10 6:40 PM, Karl Wright wrote: > Vote +1 to rename Apache Connectors Framework to Apache ManifoldCF. > Vote -1 to keep the project name of Connectors Framework, or to retain > Connex, if that wins its vote. > > This vote also expires end of day on Friday. > > Note: "Manifold" is a trademark for a GIS software product. However, > I agree with Grant that ManifoldCF appearing under the Apache label > should be safe to be used. But you should recognize that this vote is > not merely a referendum on the name itself, but also on the > suitability of the name in a legal context. > > Karl
Re: [VOTE] Select a name to possibly replace Apache Connectors Framework
1.ManifoldCF 2.Connex -Mark On 9/28/10 4:44 PM, Jack Krupansky wrote: > My votes: > > Connex > Connie > Contango > Contour > Manicon > Multicon > Ralph > Repositor > > (In alpha order, no preference implied.) > > -- Jack Krupansky > > -- > From: "Karl Wright" > Sent: Tuesday, September 28, 2010 11:03 AM > To: > Subject: Re: [VOTE] Select a name to possibly replace Apache Connectors > Framework > >> Reminder: six hours to go. (Jack, I still haven't seen your vote...) >> >> Karl >> >> On Tue, Sep 28, 2010 at 5:53 AM, George Aroush wrote: >>> Ayvitraya >>> >>> -- George >>> >>> -Original Message- >>> From: Karl Wright [mailto:daddy...@gmail.com] >>> Sent: Thursday, September 23, 2010 5:29 PM >>> To: connectors-dev >>> Subject: [VOTE] Select a name to possibly replace Apache Connectors >>> Framework >>> >>> Folks, >>> >>> Grant feels we would have a better chance of graduating from >>> incubation without changes if we adopt a new name. There will thus be >>> two votes. First vote is designed to arrive at a name, and the second >>> vote will be on whether to use that highest-point name instead of >>> Apache Connectors Framework. >>> >>> Because the list is quite long this time, please select your favorite >>> 8 choices, in order of preference. If you submit duplicate choices, >>> only the first of each duplicate will be counted, and the others will >>> receive zero points. So it is in your interest to not select any >>> duplicates. All of these choices have been already screened to >>> fulfill specific criteria, such as avoidance of trademarks or heavily >>> used words. >>> >>> The list of candidates is: >>> >>> Ayvitraya >>> Conex >>> Connex >>> Connie >>> Connx >>> Contango >>> Conton >>> Contor >>> Contour >>> Conx >>> Heterolink >>> Heterosource >>> Heteroweb >>> Manicon >>> ManifoldCF >>> Manifolio >>> Manilink >>> Maniplex >>> Manisource >>> Maniweb >>> Multicon >>> Multiconnect >>> Multiconnex >>> Ralph >>> Reconto >>> RepoMan >>> Repositor >>> Recon >>> Reconex >>> Reconn >>> Reconnex >>> Reconnx >>> Reconx >>> >>> Let the voting begin! >>> Karl >>> >>>
Re: Exploring ManifoldCF ramifications
On 9/21/10 10:08 AM, Karl Wright wrote: > The exception naming issue is noted, but that's really a separate > problem. The IOException exception comes from the IO subsystem, and > it's the base exception of everything from an encoding exception > through a socket problem through a timeout. ACFException is a similar > base exception class, except it comes from ACF. So there is a rough > parity there. If you want to challenge the use of base exception > classes, so be it, but that's not the difficulty with ManifoldCF. You're not on your own here - see the heavily used SolrException from Solr ;)
[jira] Commented: (CONNECTORS-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908561#action_12908561
]
Mark Miller commented on CONNECTORS-98:
---
I agree - I think the best REST is sticking by most of the general practices as
you can / makes sense - but more importantly, just be consistent. While it can
be nice to stick to the http spec / REST gospel when you can, sometimes it just
makes sense to be a little different.
bq. (2) HTTP states that PUT should generate a 201 return when the resource is
being created.
Both PUT and POST can be used to create according to HTTP.
bq. (3) Use of plural/singular. I don't really care much. Pick something and
let me know and we'll stick with it.
I agree - it's only important to be consistant internally here - otherwise, who
cares.
> API should be "pure" RESTful with the API verb represented using the HTTP
> GET/PUT/POST/DELETE methods
> -
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
>Affects Versions: LCF Release 0.5
>Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the
> API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
> input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> What we have today is certainly workable, but just not as "pure" as some
> might desire. It would be better to take care of this before the initial
> release so that we never have to answer the question of why it wasn't done as
> a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can
> process the DELETE and PUT methods (using the doDelete and doPut method
> overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have
> large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Pick your preferred name
On 9/2/10 8:21 AM, Karl Wright wrote: > You have until 5 PM Friday to tally your final vote. > > Bear in mind, however, that changing your vote to achieve a desired outcome > may well cause others to change their votes to counteract your move. So I > urge people to change your vote ONLY if you want to add Apache Datasource > Connectors into your list somewhere. > > Karl > It's probably a fair move though - I doubt Jack realized how the votes would be tallied (eg that Roberts vote would have so much weight for one name). I had no clue - the original vote sounded like you needed to pick 3 different options and didn't explain how those options would count towards the final name. So it seems fair that he change it, right? - Mark
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
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
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: About name change
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
Re: About name change
Heh - only with an extremely liberal definition of multiword. The list really speaks for itself here. > (I'm not including commons or jakarta in this, because they are multiple > projects) > They are each a single top level project with many sub projects. On 8/30/10 5:06 PM, Karl Wright wrote: > Ok, let's do a count. > > Single word: 49 > Multiword: 26 > > (I'm not including commons or jakarta in this, because they are multiple > projects) > > Karl > > > On Mon, Aug 30, 2010 at 4:59 PM, Mark Miller wrote: > >> Right - mashed together into one word - not multiple words. And if you >> look, it's not even a 'lot' without the bold around it ;) >> >> On 8/30/10 4:50 PM, Karl Wright wrote: >>> TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of >> names >>> that are multiple words. They're just mashed together. ;-) >>> >>> Karl >>> >>> On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller >> wrote: >>> >>>> On 8/30/10 1:37 PM, Karl Wright wrote: >>>>> snip - Consider using functional names, especially for products of >>>> existing >>>>> projects, e.g. for an "Apache Foo" project, the product name "Apache >> Foo >>>>> Pipelines". -snip >>>>> >>>>> Granted, "Lucene Connectors Framework" fills this to a T, but this >> would >>>>> imply that functional names are OK for top-level projects too. >>>> >>>> FYI, these are listed as guidelines, so I don't think they are meant to >>>> determine what is OK or not. A guideline is by definition not mandatory. >>>> >>>> It would seem to me that the reason this is emphasized for subprojects >>>> of foo even more so than foo, is that foo will already be a unique >>>> simple abstract name. After you have that, it's best to be descriptive >>>> for sub projects. If you don't have a unique simple abstract 'component' >>>> of the name for a top level project, many of the other guidelines are >>>> not met very well. >>>> >>>> Below are some current Apache project names - you start to see a pattern >>>> - notice that most of them will be the top hit on google using simply >>>> the name (yes, including ant, tiles and felix surprisingly ;) ). This >>>> isn't always the case of course - many different historical issues >>>> factor into these names - but as you can see - even just more than one >>>> word for the name is extremely uncommon. >>>> >>>> HTTP Server >>>> Abdera >>>> ActiveMQ >>>> Ant >>>> APR >>>> Archiva >>>> Avro >>>> Buildr >>>> Camel >>>> Cassandra >>>> Cayenne >>>> Click >>>> Cocoon >>>> Commons >>>> Continuum >>>> CouchDB >>>> CXF >>>> DB >>>> Directory >>>> Excalibur >>>> Felix >>>> Forrest >>>> Geronimo >>>> Gump >>>> Hadoop >>>> Harmony >>>> HBase >>>> HttpComponents >>>> Jackrabbit >>>> Jakarta >>>> James >>>> Lenya >>>> Logging >>>> Lucene >>>> Mahout >>>> Maven >>>> Mina >>>> MyFaces >>>> Nutch >>>> ODE >>>> OFBiz >>>> OpenEJB >>>> OpenJPA >>>> OpenWebBeans >>>> PDFBox >>>> Perl >>>> Pivot >>>> POI >>>> Portals >>>> Qpid >>>> Roller >>>> Santuario >>>> ServiceMix >>>> Shindig >>>> Sling >>>> SpamAssassin >>>> STDCXX >>>> Struts >>>> Subversion >>>> Synapse >>>> Tapestry >>>> Tika >>>> TCL >>>> Tiles >>>> Tomcat >>>> TrafficServer >>>> Turbine >>>> Tuscany >>>> UIMA >>>> Velocity >>>> Wicket >>>> Web Services >>>> Xalan >>>> Xerces >>>> XML >>>> XMLBeans >>>> XML Graphics >>>> >>>>> >>>>> Karl >>>>> >>>>> On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller >>>> wrote: >>>>> >>>>>> On 8/30/10 1:05 PM, Karl Wright wrote: >>>>>> >>>>>>> I'm not too keen on just a simple abstract name - too meaningless for >>>> me. >>>>>> >>>>>> It works for countless Apache projects (that's really the standard) - >>>>>> not really buying it would be a problem here. >>>>>> >>>>>> Also, I havn't been following closely, so if someone hasn't pointed it >>>>>> out yet, fyi on some recommendations: >>>>>> http://www.apache.org/dev/project-names.html >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >
Re: About name change
> I'm sure nobody will have a cow. Or, at > least not a very large one. ;-) > > Karl Right, but that's not a very good guiding principle for choosing an apache project name - nobody will have a cow. And yes, pretty much everyone I have ever heard talk about Lucene, calls it Lucene rather than the Lucene search engine :) But again, that's also completey besides the point of the guidelines for a good name even if it was true. The key word would be Lucene - putting anything after that will be generally fine - the Lucene component does all the heavy lifting for the naming goodness. - Mark
Re: About name change
Right - mashed together into one word - not multiple words. And if you look, it's not even a 'lot' without the bold around it ;) On 8/30/10 4:50 PM, Karl Wright wrote: > TrafficServer? OpenWebBeans? XMLBeans? There are actually a *lot* of names > that are multiple words. They're just mashed together. ;-) > > Karl > > On Mon, Aug 30, 2010 at 4:44 PM, Mark Miller wrote: > >> On 8/30/10 1:37 PM, Karl Wright wrote: >>> snip - Consider using functional names, especially for products of >> existing >>> projects, e.g. for an "Apache Foo" project, the product name "Apache Foo >>> Pipelines". -snip >>> >>> Granted, "Lucene Connectors Framework" fills this to a T, but this would >>> imply that functional names are OK for top-level projects too. >> >> FYI, these are listed as guidelines, so I don't think they are meant to >> determine what is OK or not. A guideline is by definition not mandatory. >> >> It would seem to me that the reason this is emphasized for subprojects >> of foo even more so than foo, is that foo will already be a unique >> simple abstract name. After you have that, it's best to be descriptive >> for sub projects. If you don't have a unique simple abstract 'component' >> of the name for a top level project, many of the other guidelines are >> not met very well. >> >> Below are some current Apache project names - you start to see a pattern >> - notice that most of them will be the top hit on google using simply >> the name (yes, including ant, tiles and felix surprisingly ;) ). This >> isn't always the case of course - many different historical issues >> factor into these names - but as you can see - even just more than one >> word for the name is extremely uncommon. >> >> HTTP Server >> Abdera >> ActiveMQ >> Ant >> APR >> Archiva >> Avro >> Buildr >> Camel >> Cassandra >> Cayenne >> Click >> Cocoon >> Commons >> Continuum >> CouchDB >> CXF >> DB >> Directory >> Excalibur >> Felix >> Forrest >> Geronimo >> Gump >> Hadoop >> Harmony >> HBase >> HttpComponents >> Jackrabbit >> Jakarta >> James >> Lenya >> Logging >> Lucene >> Mahout >> Maven >> Mina >> MyFaces >> Nutch >> ODE >> OFBiz >> OpenEJB >> OpenJPA >> OpenWebBeans >> PDFBox >> Perl >> Pivot >> POI >> Portals >> Qpid >> Roller >> Santuario >> ServiceMix >> Shindig >> Sling >> SpamAssassin >> STDCXX >> Struts >> Subversion >> Synapse >> Tapestry >> Tika >> TCL >> Tiles >> Tomcat >> TrafficServer >> Turbine >> Tuscany >> UIMA >> Velocity >> Wicket >> Web Services >> Xalan >> Xerces >> XML >> XMLBeans >> XML Graphics >> >>> >>> Karl >>> >>> On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller >> wrote: >>> >>>> On 8/30/10 1:05 PM, Karl Wright wrote: >>>> >>>>> I'm not too keen on just a simple abstract name - too meaningless for >> me. >>>> >>>> It works for countless Apache projects (that's really the standard) - >>>> not really buying it would be a problem here. >>>> >>>> Also, I havn't been following closely, so if someone hasn't pointed it >>>> out yet, fyi on some recommendations: >>>> http://www.apache.org/dev/project-names.html >>>> >>>> - Mark >>>> >>>> >>> >> >> >
Re: About name change
On 8/30/10 1:37 PM, Karl Wright wrote: > snip - Consider using functional names, especially for products of existing > projects, e.g. for an "Apache Foo" project, the product name "Apache Foo > Pipelines". -snip > > Granted, "Lucene Connectors Framework" fills this to a T, but this would > imply that functional names are OK for top-level projects too. FYI, these are listed as guidelines, so I don't think they are meant to determine what is OK or not. A guideline is by definition not mandatory. It would seem to me that the reason this is emphasized for subprojects of foo even more so than foo, is that foo will already be a unique simple abstract name. After you have that, it's best to be descriptive for sub projects. If you don't have a unique simple abstract 'component' of the name for a top level project, many of the other guidelines are not met very well. Below are some current Apache project names - you start to see a pattern - notice that most of them will be the top hit on google using simply the name (yes, including ant, tiles and felix surprisingly ;) ). This isn't always the case of course - many different historical issues factor into these names - but as you can see - even just more than one word for the name is extremely uncommon. HTTP Server Abdera ActiveMQ Ant APR Archiva Avro Buildr Camel Cassandra Cayenne Click Cocoon Commons Continuum CouchDB CXF DB Directory Excalibur Felix Forrest Geronimo Gump Hadoop Harmony HBase HttpComponents Jackrabbit Jakarta James Lenya Logging Lucene Mahout Maven Mina MyFaces Nutch ODE OFBiz OpenEJB OpenJPA OpenWebBeans PDFBox Perl Pivot POI Portals Qpid Roller Santuario ServiceMix Shindig Sling SpamAssassin STDCXX Struts Subversion Synapse Tapestry Tika TCL Tiles Tomcat TrafficServer Turbine Tuscany UIMA Velocity Wicket Web Services Xalan Xerces XML XMLBeans XML Graphics > > Karl > > On Mon, Aug 30, 2010 at 1:24 PM, Mark Miller wrote: > >> On 8/30/10 1:05 PM, Karl Wright wrote: >> >>> I'm not too keen on just a simple abstract name - too meaningless for me. >> >> It works for countless Apache projects (that's really the standard) - >> not really buying it would be a problem here. >> >> Also, I havn't been following closely, so if someone hasn't pointed it >> out yet, fyi on some recommendations: >> http://www.apache.org/dev/project-names.html >> >> - Mark >> >> >
Re: About name change
On 8/30/10 1:05 PM, Karl Wright wrote: > I'm not too keen on just a simple abstract name - too meaningless for me. It works for countless Apache projects (that's really the standard) - not really buying it would be a problem here. Also, I havn't been following closely, so if someone hasn't pointed it out yet, fyi on some recommendations: http://www.apache.org/dev/project-names.html - Mark
[jira] Commented: (CONNECTORS-56) All features should be accessible through an API
[ https://issues.apache.org/jira/browse/CONNECTORS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902940#action_12902940 ] Mark Miller commented on CONNECTORS-56: --- bq. HTTP methods other than GET or PUT are in fact poorly supported in many HTTP clients, including Apache Commons HTTPClient. That's untrue. bq. I am also unsure of whether Jetty supports the DELETE method at the servlet level. Jetty has no issues with DELETE, POST, PUT, or GET. Nor does Tomcat or any other container I have seen. bq. I therefore think your suggestion would potentially cause a great deal of headache for no tangible benefit. Again, I don't agree - it would cause less headaches, as REST is somewhat of a standard rather than an ad hoc api. There are many advantages to having a consistent RESTful api. > All features should be accessible through an API > > > Key: CONNECTORS-56 > URL: https://issues.apache.org/jira/browse/CONNECTORS-56 > Project: Apache Connectors Framework > Issue Type: Sub-task > Components: Framework core >Reporter: Jack Krupansky >Assignee: Karl Wright > > LCF consists of a full-featured crawling engine and a full-featured user > interface to access the features of that engine, but some applications are > better served with a full API that lets the application control the crawling > engine, including creation and editing of connections and creation, editing, > and control of jobs. Put simply, everything that a user can accomplish via > the LCF UI should be doable through an LCF API. All LCF objects should be > queryable through the API. > A primary use case is Solr applications which currently use Aperture for > crawling, but would prefer the full-featured capabilities of LCF as a > crawling engine over Aperture. > I do not wish to over-specify the API in this initial description, but I > think the LCF API should probably be a traditional REST API., with some of > the API elements specified via the context path, some parameters via URL > query parameters, and complex, detailed structures as JSON (or similar.). The > precise details of the API are beyond the scope of this initial description > and will be added incrementally once the high-level approach to the API > becomes reasonably settled. > A job status and event reporting scheme is also needed in conjunction with > the LCF API. That requirement has already been captured as CONNECTORS-41. > The intention for the API is to create, edit, access, and control all of the > objects managed by LCF. The main focus is on repositories, jobs, and status, > and less about document-specific crawling information, but there may be some > benefit to querying crawling status for individual documents as well. > Nothing in this proposal should in any way limit or constrain the features > that will be available in the LCF UI. The intent is that LCF should continue > to have a full-featured UI, but in addition to a full-featured API. > Note: This issue is part of Phase 2 of the CONNECTORS-50 umbrella 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-98) API should be "pure" RESTful with the API verb represented using the HTTP GET/PUT/POST/DELETE methods
[
https://issues.apache.org/jira/browse/CONNECTORS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902941#action_12902941
]
Mark Miller commented on CONNECTORS-98:
---
bq. Also, POST should be usable as an alternative to PUT for API calls that
have large volumes of data.
That shouldn't be necessary at all.
> API should be "pure" RESTful with the API verb represented using the HTTP
> GET/PUT/POST/DELETE methods
> -
>
> Key: CONNECTORS-98
> URL: https://issues.apache.org/jira/browse/CONNECTORS-98
> Project: Apache Connectors Framework
> Issue Type: Improvement
> Components: API
>Affects Versions: LCF Release 0.5
>Reporter: Jack Krupansky
> Fix For: LCF Release 0.5
>
>
> (This was originally a comment on CONNECTORS-56 dated 7/16/2010.)
> It has come to my attention that the API would be more "pure" RESTful if the
> API verb was represented using the HTTP GET/PUT/POST/DELETE methods and the
> input argument identifier represented in the context path.
> So, GET outputconnection/get \{"connection_name":__\} would
> be GET outputconnections/
> and GET outputconnection/delete \{"connection_name":__\}
> would be DELETE outputconnections/
> and GET outputconnection/list would be GET outputconnections
> and PUT outputconnection/save
> \{"outputconnection":__\} would be PUT
> outputconnections/
> \{"outputconnection":__\}
> What we have today is certainly workable, but just not as "pure" as some
> might desire. It would be better to take care of this before the initial
> release so that we never have to answer the question of why it wasn't done as
> a "proper" RESTful API.
> BTW, I did check to verify that an HttpServlet running under Jetty can
> process the DELETE and PUT methods (using the doDelete and doPut method
> overrides.)
> Also, POST should be usable as an alternative to PUT for API calls that have
> large volumes of data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Need an opinion, on whether to change package or not
+1 to renaming the package - nows the time. - Mark http://www.lucidimagination.com (mobile) On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" wrote: > +1 > > -- Jack Krupansky > > -- > From: "Karl Wright" > Sent: Sunday, August 22, 2010 1:49 PM > To: "connectors-dev" > Subject: Need an opinion, on whether to change package or not > >> Consider this an official request for a vote. >> >> +1 indicates you think we should change the following in the source code, as >> soon as is practical: >> >> org.apache.lcf.xxx -> org.apache.acf.xxx >> All classes LCF.java and LCFException.java should change to ACF.java and >> ACFException.java >> >> Bear in mind that users of ACF/LCF who currently have existing database >> instances will need to reinitialize those instances if we do this change. >> This is because the class names of connectors are stored in the database >> when the connector is registered. >> >> (FWIW, my vote on this is -1. It doesn't seem worth the disruption. But I >> will of course abide by the consensus.) >> >> Vote will be considered closed by Wednesday evening, so vote early (and >> often. ;-)) >> Karl
[jira] Commented: (CONNECTORS-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886718#action_12886718 ] Mark Miller commented on CONNECTORS-55: --- If it's now that easy, then fantastic! The last quick start guide I saw was like many thousands of words, so it's nice to see it boiled down to like a dozen ;) That is exactly what I was leaning towards - but what kind of hobbled state are you in with derby? You said you have to run the db and ui one at a time or something? And that many sql queries don't work with derby - that has all been addressed already? Anyhow, you asked what my goal was for pushing getting a working java db - and this is exactly it. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella 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-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886715#action_12886715 ] Mark Miller commented on CONNECTORS-55: --- bq. Jack, for example, was extremely surprised to learn that embedded Derby would not allow more than one process to access the database at a time You can switch to a mode that allows multiple connections - I've started with one and moved to the other in the past - its been too long so I'd have to go look, but its entirely possible to use very similar code and run in a server mode. bq. so that we could understand your true goal here. To make trying out and installing LCF much easier - the bar on this thing as a user and a dev is just kind of ridiculous at the moment. I know a lot of improvements are being made, but having to install a separate postgres db just to get going - just to try LCF out - is something I'd like to see go away. A java db would allow us to get to a point where you download the thing and launch it - that would really get this project going. It will be helpful to attract both users and a community of devs. There are at least half a dozen or more committers that signed up for this project, but the bar is so high to even 'do anything', that I suspect thats why most of them have yet to contribute even a comment - they don't have the time or motivation to go through that huge 'running LCF' doc - its a bear just to skim, say nothing about go through the steps. In general, I like to think of all that work as something the computer can do for me ;) Baby steps though - I'm just pushing in that direction - I know there would be a long, long path to get there. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella 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-55) Bundle database server with LCF packaged product
[ https://issues.apache.org/jira/browse/CONNECTORS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886494#action_12886494 ] Mark Miller commented on CONNECTORS-55: --- All the more reason to get LCF working completely with other Java databases. > Bundle database server with LCF packaged product > > > Key: CONNECTORS-55 > URL: https://issues.apache.org/jira/browse/CONNECTORS-55 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Jack Krupansky > > The current requirement that the user install and deploy a PostgreSQL server > complicates the installation and deployment of LCF for the user. Installation > and deployment of LCF should be as simple as Solr itself. QuickStart is great > for the low-end and basic evaluation, but a comparable level of simplified > installation and deployment is still needed for full-blown, high-end > environments that need the full performance of a ProstgreSQL-class database > server. So, PostgreSQL should be bundled with the packaged release of LCF so > that installation and deployment of LCF will automatically install and deploy > a subset of the full PostgreSQL distribution that is sufficient for the needs > of LCF. Starting LCF, with or without the LCF UI, should automatically start > the database server. Shutting down LCF should also shutdown the database > server process. > A typical use case would be for a non-developer who is comfortable with Solr > and simply wants to crawl documents from, for example, a SharePoint > repository and feed them into Solr. QuickStart should work well for the low > end or in the early stages of evaluation, but the user would prefer to > evaluate "the real thing" with something resembling a production crawl of > thousands of documents. Such a user might not be a hard-core developer or be > comfortable fiddling with a lot of software components simply to do one > conceptually simple operation. > It should still be possible for the user to supply database server settings > to override the defaults, but the LCF package should have all of the > best-practice settings deemed appropriate for use with LCF. > One downside is that installation and deployment will be platform-specific > since there are multiple processes and PostgreSQL itself requires a > platform-specific installation. > This proposal presumes that PostgreSQL is the best option for the foreseeable > future, but nothing here is intended to preclude support for other database > servers in futures releases. > This proposal should not have any impact on QuickStart packaging or > deployment. > Note: This issue is part of Phase 1 of the CONNECTORS-50 umbrella 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-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879182#action_12879182 ] Mark Miller commented on CONNECTORS-40: --- bq. could you summarize what you are up to with this issue? To clarify, I mean could you summarize the approach you are taking with the current work you have done on the branch. > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879107#action_12879107 ] Mark Miller edited comment on CONNECTORS-40 at 6/15/10 7:32 PM: FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 This issue is being developed on a branch at http://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-40 was (Author: markrmil...@gmail.com): FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879178#action_12879178 ] Mark Miller commented on CONNECTORS-40: --- >From >http://search.lucidimagination.com/search/document/760aeaa785116e3b/beginning_of_connectors_40_work > : Hi all (and especially Eric), I began work on CONNECTORS-40 in the agreed-upon branch. So far, I've checked in the modifications needed to pull output connector UI out of JSP, and also did the conversion of the gts output connector from JSP. This looks reasonably good to me, other than the somewhat-more-obtuse syntax required to represent HTML from within the java connector classes. But it would be good to hear any comments before I go further in the conversion process. Thanks, Karl Mark: you can find a link to the diffs ref'd here: http://mail-archives.apache.org/mod_mbox/incubator-connectors-commits/201006.mbox/%3c20100615191345.6a2072388...@eris.apache.org%3e > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879174#action_12879174 ] Mark Miller commented on CONNECTORS-40: --- Hey Karl - To lower the bar for contributers (say those with ideas but not the time to jump into code), could you summarize what you are up to with this issue? It also is difficult to casually follow along with this issue especially as it is broken up over the mailing list, a branch, and JIRA. Ideally everything one would want to follow along would be in the JIRA issue itself. In that spirit, I'll post some more useful info. > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-40) Classloader-based plug-in architecture would permit LCF to be prebuilt
[ https://issues.apache.org/jira/browse/CONNECTORS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879107#action_12879107 ] Mark Miller commented on CONNECTORS-40: --- FYI: http://search.lucidimagination.com/search/document/1b60f001fc0a0a98/branch_for_ticket_connectors_40 > Classloader-based plug-in architecture would permit LCF to be prebuilt > -- > > Key: CONNECTORS-40 > URL: https://issues.apache.org/jira/browse/CONNECTORS-40 > Project: Lucene Connector Framework > Issue Type: Improvement > Components: Framework core >Reporter: Karl Wright > > The LCF architecture at this point requires interaction with the build script > in order to add connectors. This is because the connector JSPs and jars need > to be added to the appropriate war files. However, there is another > architectural option that would eliminate this need, which is to use a custom > classloader to pull components from jars that are placed in a specific > directory or directories. > In order for this to work, however, the UI components of every connector must > become part of a jar. That implies that they will need to cease being JSPs, > and become instead methods of each connector class. (There is no > proscription against using something like Velocity for assembling the > necessary output for a connector, however.) Limiting the > backwards-compatibility impact of this change will be difficult, especially > after a first release is made, so it seems clear that any change along these > lines should be attempted before version 1.0 is released. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: LCF report missing
On 6/14/10 11:22 AM, Jukka Zitting wrote: Hi, I guess nobody took up the task of writing an LCF report for this months board meeting [1]. I was quite busy last week so I unfortunately didn't notice this in time. Sorry about that. The missing report is not too big a deal, but we'll need to submit an extra report next month. [1] http://wiki.apache.org/incubator/June2010 BR, Jukka Zitting Looks like they want it now. Like, right NOW! :) -- - Mark http://www.lucidimagination.com
Re: Derby/JUnit bad interaction - any ideas?
On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to "read-only". Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl So I've been thinking about this - I still have trouble believing this is a real problem. I had a large suite of tests that used embedded derby in a system I worked on a few years back - and I never had any trouble removing the db dir after shutting down derby. Looking at the code, have you actually tried shutting down derby? Currently you have: // Cause database to shut down new Database(context,_url+databaseName+";shutdown=true",_driver,databaseName,"",""); // DO NOT delete user or shutdown database, since this is in fact impossible under java 1.5 (since Derby makes its directories read-only, and // there's no way to undo that... // rm -rf //File f = new File(databaseName); //recursiveDelete(f); But that is not going to do the shutdown? On a quick look, doing new Database(context, url ... does not actually contact the db - so its not going to cause it to shutdown? Is this just cruft code and you have actually tried shutting down as well? Something makes me think the delete is going to work if you actually attempt to connect with '...;shutdown=true' jdbc URL. -- - Mark http://www.lucidimagination.com
[jira] Created: (CONNECTORS-43) Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
---
Key: CONNECTORS-43
URL: https://issues.apache.org/jira/browse/CONNECTORS-43
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Priority: Trivial
{code}
nextString.trim();
{code}
should likely be:
{code}
nextString = nextString.trim();
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONNECTORS-42) Impossible cast in org.apache.lcf.core.database.Database
Impossible cast in org.apache.lcf.core.database.Database
Key: CONNECTORS-42
URL: https://issues.apache.org/jira/browse/CONNECTORS-42
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Priority: Minor
{code}
if (x instanceof TimeMarker)
{
ps.setTimestamp(i+1,new java.sql.Timestamp(((Long)x).longValue()));
}
{code}
should likely be:
{code}
if (x instanceof TimeMarker)
{
ps.setTimestamp(i+1,new
java.sql.Timestamp(((TimeMarker)x).longValue()));
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Derby/JUnit bad interaction - any ideas?
On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to "read-only". Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Interesting - when I worked with derby in the past, I never had any trouble deleting a database after shutting it down on windows using Java 5. It worked great with my unit tests. You could always run each test in a new system tmp dir every time... I find it hard to believe you cannot delete the database somehow though - like I said, I never had any problems with it using embedded derby in the past after shutting down the db. -- - Mark http://www.lucidimagination.com
Re: Grant, would you like to kick off a logo context?
On 03/05/2010 09:47 AM, Grant Ingersoll wrote: On Mar 4, 2010, at 12:31 PM, Karl Wright wrote: Folks seem to think this page is a good way to start: http://wiki.apache.org/solr/LogoContest Do we have sponsors for such a thing? When I referred to that page, I was pointing more towards the guidelines for a logo rather than the contest itself. And not every project has followed those guidelines, but apparently they are what Apache would like. - Mark Unfortunately, I don't have ability to view the wiki source of this document, or I'd be happy to do it... You just need to login. You likely need a different user id.
Re: Logo possibilities
Karl Wright wrote: > > Hi, > > I've posted some possible logos in the wiki - see > http://cwiki.apache.org/confluence/display/CONNECTORS/Possible+Logos . > The person who did these is willing to revise/do more, with proper > incentive. ;-) Please post your thoughts about appropriateness for > LCF, or if you feel strongly enough, just go ahead and cast your vote > for one of the choices, bearing in mind that if I solicit more > artwork, we all may need to vote again. ;-) > > Thanks, > Karl > Thanks for soliciting the logo's Karl! I put up a rough option of my own, as I personally favor simpler logos than whats up there now - more as inspiration of an option I'd like to have to vote on than a real entry (its a bit rough and not in vector format). -- - Mark http://www.lucidimagination.com
