Daisy has been in development since the beginning of this year and has been in active production use over the past few months. It ships with an WYSIWYG HTML Wiki editing application but its ReST-like decoupling of front- and back-end enables many other uses and applications.

Daisy consists of a standalone repository server and a comprehensive browsing and editing Wiki-style editing application. The server exposes its functionality over an XML/HTTP interface, which has also been embedded in a remote, high-level Java API. The front-end DaisyWiki application runs inside the Apache Cocoon framework which makes Daisy ideally suited for management of content-dense, multiple-platform websites.

Some differentiating features of Daisy are:

* a "document type" concept, i.e. providing a grammar and UI for specifying document fields and parts
* hierarchy-less storage of documents: Daisy prefers management, retrieval and classification of documents with metadata over the classic "directory structure" approach
* a centralized ACL configuration, where ACL are attached to categories of documents, expressed using a SQL-like expression language
* automatic cleanup of rich text parts into a near-XHTML grammar, which makes cross-browser editing of Daisy content a breeze
* simultaneous storage and querying of document content over a relational database, filesystem and Lucene-based fulltext indexes from the same query language
* the ability to include query results inside documents and navigation trees
* versioning of document content with CVS/SVN-like diffing capabilities

Daisy is available from http://cocoondev.org/daisy/ and comes with extensive documentation.

Daisy ships under the Apache License 2.0. Outherthought has gathered acclaimed expertise with open source framework development within the Apache Cocoon community and also its open source web-based database reporting engine xReporter.

Outerthought will be presenting Daisy during the Cocoon GetTogether - to be held 11-12 October in Ghent, Belgium.

I would like to see a live demo of the editors and admin functions if one is available. Couldn't find anything on the web site.

I would like to see a live demo of the editors and admin functions if one is available. Couldn't find anything on the web site.

Chris,

I think http://cocoondev.org/daisy/ itself is one CMS, isn't it?:)

I've added a few screenshots of the password-protected parts of the Daisy site: http://cocoondev.org/daisy/53

This is I'm sure a great effort and a cool piece of technology. But why did they (and this community in general) reinvent the wheel ? Would it not make more sense to take an existing open src CMS and extend that ?

The fact that you reinvented that particular wheel and propose your own Java API instead of leveraging and extending JSR 170, Java Content Repository API is too bad.
I think it seriously limits your chances of getting the large adoption that the featureset you provide would justify. I haven't looked at your APIs in details but skimming through it there seemed to be many similarities. Do you have plans to implement JSR 170?

I think cocoon and jackrabbit (jsr 170) are different concepts. It is not easy to switch to jsr 170 once you created a cms. But - just use magnolia and you get your jsr 170 based opensource cms.

Re: demo site.

We tried to make the download & install as easy as possible, so one should be able to get Daisy up & running quite easily. I'll try to put up some screenshots of the editing/admin section on the site. I've been hosting a high-profile (Cocoon-centric) Wiki for the past year and I'm very concerned about spamming and abuse.

Re: JSR170.

"The nice thing about standards is the number of standards to choose from." What we see is that many implementations only do 80% of the spec, which is like an XML-parser without namespaces support. So you end up with clients and servers which don't connect well with each other - because they implement the specification differently (or not at all). We did take a look at JSR170 (also please mind that the JSR wasn't public yet when we started Daisy development) and it wasn't really finished at that time. The non-hierarchical storage model didn't fit well into the WebDAV/JSR170 concept, nor the SQL-like query language.

With Daisy, we tried to focus on functionalities: make it easy for developers to build a CMS-enabled web application. That means we have a nice high-level Java API, and we don't expect folks having to spend much thinking about <em>how</em> they are going to use repository XYZ to build a CMS app - they can just start and do it.

Re: Magnolia

Daisy's licensing philosophy is totally different. We'd rather see Daisy used as widely as possible, unencumbered by reciprocal license conditions, and then see few users become customers and pay us to add more stuff to Daisy. This is what Outerthought has been doing for the past years now (also with http://xreporter.cocoondev.org) and we're quite happy with this model.

License:

- In my opinion there are minor differences for the use and reuse of the system or components out of an os-cms with LGPL or Apache license.

- The business model is about the same : Magnolia International is responsible for the Marketing, Community and for the improvement of magnolia and obinary ltd. implements projects and extends magnolia.
 
In the End I see only minor differences, but however - good luck with your project, it looks promising
pascal

Hi there,

I'm starting an evaluation period over Daisy CMS and I would like to get document publication examples from a JAVA client using the Remote Implementation of Daisy API (like Daisy Wiki does over RemoteRepositoryManager). Any help about this?

Thanks...

I have just started to evaluate Daisy and I fell in love with it instantly! The clear separation of presentation and content repository is exactly what I've been looking for but so many times before got disappointed of when trying out other Java CMS's.

The choice of a wiki as default admin frontend is simply brilliant. It gives a soft (but serious) and non technical user experience. And the flower logo is just so cute, isn't it? :)

And now, for a question. I have tried out the ACL and query language today and it sure works fine, but I think I have found a thing that does not fulfill my needs. I am thinking of using the collections on a site for areas belonging to different roles, one or more collections per area and role. Is there a way to assign collections to roles/users so that they have only this limited number of collections to choose from when creating new / editing documents? If not, is this a possible future feature?

I do not want to make it possible for one role to create documents and assign it to a collection that is not intended for that specific role.

Anyway, thanks for a great CMS!

/Henrik