[offline] Hi Juan Pablo,
Thanks for the info, that's very helpful. I've updated my Eclipse from the master but still get one error, a generics mismatch on rss.jsp. But for whatever reason that's there it won't stop me from continuing. It does sound like I should work from a branch though, not necessarily for the plugins, but for the providers, as there might be some contention there. How does one go about creating a branch, and what might be an appropriate name? To give you an idea of what I'm working on, it's a set of three providers, based on a text-based format for wiki pages called a "Ned" (as my parent project is called 'ne' and it's referred to as a "ne node"), A Ned is a text format, using a model influenced by the original Macintosh file format, which divided the file content into a "resource fork" (file metadata) and a "data fork" (file content). This uses an untypeable delimiter character to separate the forks. I've currently got four providers, three of which are finished: 1. an in-memory provider for testing only 2. a Berkeley DB JE based provider 3. a Neo4j Embedded graph database provider 4. a Neo4j OGM graph database provider (unfinished) It wouldn't be too difficult to develop a file-based provider since there are already Ned serialiser and deserialiser methods in the code. The Neo4j providers have a 32K data limitation on any single property, (due to a current limitation in Neo4j) so wiki pages over 32K get segmented and re-built when pulled from the repository. Full-text and field-based search is currently via Lucene using a separate, non-JSPWiki API, not sure what to do about that. I haven't advertised this project to the group yet because I'm not sure I'll have enough time to actually convert it over to JSPWiki and get it up and running on my own. I can probably publish some of the plugins but the providers are a significantly larger venture. While the benefits of a graph database backend for a wiki may be apparent to some, the Berkeley DB version is probably enough of a win to promote the basic Ned project, even without the Neo4j providers. It's exceedingly fast and is a very stable DB. This all comes out of a project called 'ne', a CLI-based application I've written to capture and store text-based notes. Basically, the idea is that one could write notes that are easily turned directly into wiki pages, without needing to use a wiki. Ne also has a directory watcher that can auto-ingest anything dropped into it. It's got more features than that, suffice it to say that the Neo4j providers are coming out of ne's storage backend, which is an embedded Neo4j. Ne's metadata model is configurable via a JSON file. Ne uses a more complicated model than JSPWiki but they're by design compatible. As you may imagine, the enemy in all this is, as always, time available. ...enough for now. Cheers, Murray ........................................................................... Murray Altheim <murray18 at altheim dot com> = = === http://www.altheim.com/murray/ === === = = === In the evening The rice leaves in the garden Rustle in the autumn wind That blows through my reed hut. -- Minamoto no Tsunenobu
