Re: LCF report missing
I filled it today. On Jun 14, 2010, at 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
RE: LCF report missing
Thanks - I fought with wiki.apache.org a while this morning, reset my password again, and now I have access too. So next month I should be able to plop it in there again. Karl -Original Message- From: Grant Ingersoll [mailto:gsi...@gmail.com] On Behalf Of ext Grant Ingersoll Sent: Tuesday, June 15, 2010 8:39 AM To: connectors-dev@incubator.apache.org Subject: Re: LCF report missing I filled it today. On Jun 14, 2010, at 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
Re: Incubator Board Report June 2010
Sorry for the delay, I was traveling. I have updated the agenda as well. Here is the Lucene Connector Framework section: = Lucene Connector Framework = Description Lucene Connectors Framework is an incremental crawler framework and set of connectors designed to pull documents from various kinds of repositories into search engine indexes or other targets. The current bevy of connectors includes Documentum (EMC), FileNet (IBM), LiveLink (OpenText), Patriarch (Memex), Meridio (Autonomy), SharePoint (Microsoft), RSS feeds, and web content. Lucene Connectors Framework also provides components for individual document security within a target search engine, so that repository security access conventions can be enforced in the search results. Lucene Connectors Framework has been in incubation since January, 2010. A list of the three most important issues to address in the move towards graduation 1. Javadoc and nightly builds need to be set up 1. The first official release needs to be planned and executed 1. Unit tests need to be completed Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? 1. We'd like to know whether there is any official Apache position on inclusion of NTLM implementations in ASF projects, since we've gotten mixed signals on this from other developers. This represents a crucial piece of functionality needed to support LiveLink, Meridio, SharePoint, RSS, and Web connectors properly. How has the community developed since the last report? 1. A number of people outside the committers group have been using this project, and there are lively discussions in the newsgroups. 1. LCF was presented at Lucene/Solr Eurocon to quite a bit of interest. How has the project developed since the last report? Online end-user documentation is coming along and is perhaps 90% complete. Integration with Derby has been undertaken to allow for a robust Junit test framework. On Jun 14, 2010, at 1:22 PM, Noel J. Bergman wrote: Felix Meschberger resigned as a Mentor for Chemistry. Jean Anderston was removed (emeritus) from the Incubator PMC at her request. The PMC and Chair thank them both for their service to the Incubator and the ASF. On that same note, I'd like to thank Sebastian Bazley, Joe Schaefer, and others for their continued efforts in striving for data and other consistency within the Incubator and across the ASF. Nuvem, a cross-clould API, has been proposed to the Incubator. BlueSky's lost report from last month is included this month. The project has had essentially no mailing list activity for two months, and no commits since January. Both Lucene Connector Framework and River failed to report. They have been active, are aware of, and apologize for, missing the report, and plan to provide one next month. Lucene Connector Framework just reported IP Clearence in late May. --- = Amber = Amber is a project to develop a Java library which provides an API specification for, and an unconditionally compliant implementation of the OAuth v1.0, v1.0a and v2.0 specifications. OAuth is a mechanism that allows users to authenticate and authorise access by another party to resources they control while avoiding the need to share their username and password credentials. The most important issues that must be addressed before graduation are: 1. One 2. Two 3. Three The Incubator PMC / ASF Board should be aware that: The community is in the first stages of formation and solely consists of the developers. The project has begun with the contribution of code from the initial developers. = Aries = Aries will deliver a set of pluggable Java components enabling an enterprise OSGi application programming model. Aries entered incubation on September 22, 2009. There are currently no issues requiring IPMC or Board attention. The following sub-components are actively being developed: * Application * Subsystems * Blueprint * JMX * JPA Several new sample applications have been developed to demonstrate the Aries functionality. There continues to be a vibrant community as shown by the activity on the mailing list this year. On May 26th we released Apache Aries 0.1-incubating, our first release. Top 2 or 3 things to resolve before graduation: * Build community [done] * Create a release [done] * Address project scope concerns raised during acceptance vote = BeanValidation = Apache Bean Validation will deliver an implementation of the JSR303 Bean Validation 1.0 specification. BVAL entered incubation on March 1, 2010. A list of the three most important issues to address in the move towards graduation * First release of artifacts. * Grow the community and committer base. Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * None at this time. How has the community developed since the last report * Committer offer was extended and accepted
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
[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] 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=12879193#action_12879193 ] Erik Hatcher commented on CONNECTORS-40: At first glance, this looks like a great first step towards ridding LCF of JSPs. 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-tabpanelfocusedCommentId=12879215#action_12879215 ] Karl Wright commented on CONNECTORS-40: --- The implementation strategy is as follows: (1) Add methods to the connector interfaces to support the UI. These correspond directly to the chunks of UI contributed by each connector that used to be performed by jsps, which used to be located by a naming technique. (Every connector had a family of jsps, e.g. output/connector_name/headerconfig.jsp, output/connector_name/editconfig.jsp, etc.) To do this in a way that will make it possible to easily replace the technology for the framework side of the UI later, I also introduced some interfaces so that there are no direct references to any JSP or servlet classes. (2) Change the framework UI to call the connector methods rather than the old jsp components. (3) Change all individual connectors to discard their JSPs and instead implement the connector methods. Once this preliminary work is done, it should be possible to write a class loader to allow a user (or an installer) to specify a set of paths in which to search for jars. This would make it possible for people to deliver connectors into the system without having to rebuild the war file, which currently is necessary. That, in turn, makes it feasible to prebuild all LCF components and deliver it much like Solr is delivered. The CONNECTORS-40 branch currently contains just the following: - UI method additions to the output connection interface only; - Changes to the framework UI code to call the new methods; - Changes to the GTS output connector to implement the new methods (and remove the old JSPs). The reason this has been checked in at this point is largely as a sanity check. It's a lot easier to change direction when one connector has been done than it would be to change 15 of them. Hope this helps. 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.
