[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-tabpanelfocusedCommentId=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: [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 u...@odoko.co.uk 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 daddy...@gmail.com 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 jack.krupan...@lucidimagination.com 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 daddy...@gmail.com Sent: Tuesday, September 28, 2010 7:25 PM To: connectors-dev@incubator.apache.org 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 markrmil...@gmail.com 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. 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 daddy...@gmail.com Sent: Tuesday, September 28, 2010 6:52 PM To: connectors-dev@incubator.apache.org 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
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] 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 daddy...@gmail.com Sent: Tuesday, September 28, 2010 11:03 AM To: connectors-dev@incubator.apache.org 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 geo...@aroush.net 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: [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
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 daddy...@gmail.com Sent: Tuesday, September 28, 2010 6:52 PM To: connectors-dev@incubator.apache.org 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 jack.krupan...@lucidimagination.com 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 markrmil...@gmail.com Sent: Tuesday, September 28, 2010 6:43 PM To: connectors-dev@incubator.apache.org 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: 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-tabpanelfocusedCommentId=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:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
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
Apache Manifold Apache Connectors Framework Apache Yukon - mark On 8/31/10 6:54 PM, Karl Wright wrote: My preferences: Apache Connectors Framework Apache Manifold Apache Acromantula Karl On Tue, Aug 31, 2010 at 6:44 PM, Karl Wright daddy...@gmail.com wrote: I know this is un-Apache-like, but please respond to the following list with a selection, in order, of the top three names for the project currently known as Apache Connectors Framework. The choices are: Apache Connectors Framework Apache Acromantula Apache Manifold Apache ManifoldCF Apache Multiplex Apache Lucon Apache Lukon Apache Yukon Apache Macon Apache Omni Apache Omnivore Apache CMCF (yes, I just invented that one ;-) ) Apache Multivore (yes, I just invented that one too. ;-) ) I don't think I missed any? If I did, chastise me severely please. ;-) Karl
Re: 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 markrmil...@gmail.com 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 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
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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:_connection_name_\} would
be GET outputconnections/connection_name
and GET outputconnection/delete \{connection_name:_connection_name_\}
would be DELETE outputconnections/connection_name
and GET outputconnection/list would be GET outputconnections
and PUT outputconnection/save
\{outputconnection:_output_connection_object_\} would be PUT
outputconnections/connection_name
\{outputconnection:_output_connection_object_\}
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 jack.krupan...@lucidimagination.com wrote: +1 -- Jack Krupansky -- From: Karl Wright daddy...@gmail.com Sent: Sunday, August 22, 2010 1:49 PM To: connectors-dev connectors-dev@incubator.apache.org 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-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-tabpanelfocusedCommentId=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] 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.
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 databasename //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
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
