On 8 February 2011 15:17, Thorsten Scherler <[email protected]> wrote:
> 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? > Yes, I mainly created this branch to perform the changes we discussed about the documentation and the reorganisation of the trunk (DROIDS-107). I committed some changes to use the maven site plugin and I'm thinking about translating the current xdoc files into apt files. The aim is to simplify the creation of documentation. > > 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/ > > -- Bertil Chapuis Agimem Sàrl http://www.agimem.com
