http://ofbiz.116.s1.nabble.com/using-confluence-as-the-official-ofbiz-org-site-tp168937p168943.html
By way of general commentary on this: the functionality sounds great as a starting point for something that could compete well with Confluence. The functionality here is still mostly oriented at solving technical problems though, and in the case of docs.ofbiz.org there are certain functionality requirements we need that would still have to be built.
I would also be concerned with this for a public wiki unless the code that you can include in a page is extremely limited and can't do much, and even then it would be a constant security concern. If you have an internal group working on stuff then it's not such a big deal, but for a public wiki even if controlled going in that direction is a bit scary.
However it's done when there is an alternative that is totally open source, and it is one that the ASF supports or is likely to support, then we can go for it. Until then, there's not much we can do.
For this thing on its own it looks pretty cool and it will be great to see it available in an open source project.
>> I'd love to use OFBiz-based stuff instead of commercial things (even
>> open source based commercial things like the Atlassian products, of
>> which Jira actually even uses parts of OFBiz), but we just don't have
>> the functionality on the business/applications level in these areas
>> nor the resources to build them out, especially not within the time
>> frame we need them (like immediate and ongoing...).
>
> Well, if you recall, last summer during the OfBiz User's Conference, we
> were displaying some wiki based software. We're fast approaching the 1
> year mark on it's birth, and we haven't sat still with it's development.
>
> Right now, I am rewriting the basic framework in it, extracting it out
> of OfBiz proper, and making it a stand-alone project. Said project will
> be under either a BSD or ASF license; we haven't fully decided.
>
> Main features:
>
> * commons-vfs for generic file access
> * implemented filesystems:
> * COW(Copy-On-Write). Used for quick templating/extension.
> Changing a file contents is supported, as are deletes. Multiple
> parents are supported(a single directory can have multiple parent
> directories it inherits from). Also, if a parent directory is
> also COWed, then it can still walk all that. Directory listings
> function as expected.
> * flat. Attributes of files are stored in a foo@ directory, one
> file per attribute. This sits on top of COW, so overriding a
> single attribute is simple.
> * SVN. Uses libsvnjava-hl, for automatic revision control of file
> modifications. The actual SVN filesystem itself uses a generic
> revision control API, so in theory other systems could be plugged
> in.
> * BSF, with compilation support
> * Existing BSF engines were rewritten, to support dynamic class-based
> source loading. This includes the ability to load from File,
> String, URL, and FileObject(commons-vfs). The BSF API uses an
> Object as the source, so this was a straight-forward extension.
> * The new implementations also compile the source, for a large
> speedup.
> * python(jython), java(janino), php(quercus), javascript(rhino), and
> ruby(jruby) all exist in this new framework.
> * Only one extension to BSF has been made: apply allows for optionally
> specifying the type of the named arguments
> * A template engine, based on the BSF API
> * freemarker and velocity are plugged into this system
> * A macro can be written in any template language, and included in any
> template language.
> * Macros can have both parameters, and bodies.
> * A resource can be in any language; it's parent template that it is
> included into can then be in another language. Named sections can
> also be written in any language.
>
> For example, /foo has a template set to /templates/bar.
> /templates/bar then has a template of /templates/baz. /foo is a
> velocity file. bar could be an event(which could be written in
> java/python/php/ruby/javascript), that changes the text based on
> permissions, time-of-day, or phases of the moon. Like maybe
> changing the color, css, or switching left/right sides of a div.
> Then, once the event had made it's decision, the baz template would
> be used to wrapped it's output.
>
> * A resource can be a bit of text, interpeted as a template, or a bit of
> code, that is run when it is requested.
> * Code-based resources include standard events, and something we call a
> filter(bad name). A filter can do whatever kind of processing it
> wants with the rest of the path that comes after it. For example:
>
> /category/10000/0/20/summary
>
> This would show category 10000, starting and page 0, show 20 items per
> page, and show the summary of the products. What is nice about this
> approach, is it makes for very nice entries in access logs.
> * Since a resource can be either code or text, the template engine also
> works with that. A named section, parent template, or macro can
> actual be a bit of code, that does complex processing. Again, and
> example may be the easiest way to describe this.
>
> freemarker:
> <tr>
> <td>
> <@TemplateMerge name="/category/10000/0/20/summary"/>
> </td>
> <tr>
> * Most code(with the exception of the very low-level commons-vfs
> filesystems, and the single servlet) is runtime changeable. You can
> edit the actual dispatcher code at runtime, and the classloader will
> be recycled.
> * A runtime controllable(by having events run, or even editting the
> dispatcher java file itself), allows one to have very complex
> request->site mapping. One can do the normal host->site mapping, but
> could also do something based on time-of-day.
> * Something that could be done with this system, is a nice use of the
> COW feature, and the above site mapping. There could be a base
> directory, that contained all the code for a site. Then, when a
> request comes, a COWed directory that inherits from the code base
> could be selected, based on the user's locale, and possibly a geo-ip
> lookup.
>
> As a framework, is it very extensible. However, as with most projects,
> it has reach a point where it has accumulated cruft; both in the form of
> poorly implemented features, and backwards compatibility. This is the
> reason I am currently reworking it to be standalone, and a separately
> released project.
>
> However, the existing code-base has been put to quite a bit of testing.
> An example of both the framework, and the ofbiz integration, is at
>
http://checkmark.heart.org.
>