On Tue, 2011-02-08 at 10:52 +0100, Chapuis Bertil wrote: > I agree. We have to release.
So let us plan that in a new thread. > > The changes I'd like to contribute back are the following. > > - TaskQueue repleaced by java.util.Queue You committed that in /incubator/droids/branch/bchapuis, right? Still need to review it in detail, but looks good from first sight. > - Handling process reviewed. > - Factory pattern only used for Worker > - Extractors inherit from Handler => no need to parse the document twice The three points above I second. I actually using droids ATM in combination with cocoon3 which completely changes the extractor/handler pattern. So ATM I only use the queue, filter and the cocoon pipeline parser for parser/handling (I think later on you call them extractor). In the cocoon pipeline parser I am using various transformer like the solr one you provided to inject the parse result into the different third party server (solr, persistence, REST consumer, ...). The nice thing on the approach is that I can limit the transformation logic of "page of origin" to extracted data to xsl stylesheet since I use the html-generator in cocoon. The data mapping is ATM quite based on my usecase but that could be generalized (for some transformer like the solr one better then other). > - Entity renamed in Identifier > - ContentEntity renamed in Resource > - Crawler moved to droids-crawler > - Parser moved to droids-parser > - Walker moved to droids-walker > - The walker also use an Extractor > - some minor changes sounds like not to difficult to merge/switch to your branch. salu2 > > > > On 8 February 2011 10:32, Thorsten Scherler <[email protected]> wrote: > > > On Tue, 2011-02-08 at 09:50 +0100, Chapuis Bertil wrote: > > > In previous emails and jira comments I saw several people mentionning the > > > fact they have a local copy of droids which evolved too much to be merged > > > back with the trunk. This is my case, and I think Paul Rogalinski is in > > the > > > same situation. > > > > > > Since the patches have only been applied periodically on the trunk during > > > the last months, I'd love to know if someone else is in the same > > situation > > > and what can of changes they made locally. > > > > I am not sure but I see it like you describe. > > > > IMO we should release what we have right now and then plan how to merge > > back all this different versions into a new droids version. > > > > IMO the next droids version should focus on ease of reuse and a droid > > server which starts and monitors the different droids. > > > > To start with: > > * who has a version of droids which (s)he is interested to merge back > > * what are the main difference between the forge and the "original" > > * ... > > > > salu2 > > -- > > Thorsten Scherler <thorsten.at.apache.org> > > codeBusters S.L. - web based systems > > <consulting, training and solutions> > > http://www.codebusters.es/ > > -- Thorsten Scherler <thorsten.at.apache.org> codeBusters S.L. - web based systems <consulting, training and solutions> http://www.codebusters.es/
