What I’d like to achieve is a combination of the following:

• provide a better platform for users and developers alike: discussing new features and getting help should be simpler, more effective, and more rewarding.
• drive the “notification” type of traffic away from email (to RSS, for example); one can “subscribe” to the issues or filters they’re interested in. The archival of these emails provides no value, since the issue tracker itself is indexed.

Forums were all the rage a few years ago, and I’m suspecting that’s the reason there is so much forum software out there, and most of it seems incomplete, unfinished, when not abandoned altogether. On the other hand, other types of platforms have emerged, which are also very interesting for this type of application: think Reddit, StackOverflow, … “Clones” of these websites exist, and provide many of the desired functionality, but lack support for “discussions”; they seem much more adapted to question/answers.

Most of the software I tried out have their advantages, but so far, I haven’t found one that completely convinced me; this post is really a bootle-in-the-sea, hoping someone catches it and offers some insight.

Here are a few of the features I’m looking for:

• threads should be markable as “questions”. The original poster should be able to mark his question as “answered”. This would help in making sure everyone gets the help they deserve, and give a chance to everyone to help others.
• karma: frequent users, good answers, etc. should be rewarded/rewardable.
• likewise, interesting threads should be rated.
• rss feeds. (new threads, new messages in threads, “hot topics”, etc.)
• decent layout, should be simple enough to customize.
• nice URLs: eg. http://forum.magnolia-cms.com/about-this-or-that : not only is this URLs legible, it’s also better for indexing, and helps with cross-linking: it’s very likely that such discussions will end up being referenced in the wiki or the issue tracked, and vice-versa-)
• login/registration: having everyone create yet another account would annoy me: the ability to use either OpenID (including compatibility with Google accounts et al, which is apparently not always a given), or an existing user database (i.e reuse Jira accounts) would be good; additionally, LDAP connectivity would be good for our “internal” users.

So far, I’m favoring bbPress. It’s the simplest, most effective, and actually working, of those I tried. Simple Machines Forum seems to be recommended a lot; the default theme isn’t too bad, but has anyone seen any other decent theme? It also has boatloads of plugins, and it’s hard to find out which ones actually work. FluxBB also looks promising in its cleanliness and simplicity, but lacks most features mentioned above (unless there are plugins hosted elsewhere). JForum seems pretty much dead (?), and Jive’s SBS is unfortunately unaffordable.

Ultimately, I’d love to be able to use our own forum module of course, but it lacks many of the above, and we’re short on resources to develop this at the moment; we’re focusing on 5.0 first !

What do you think ? Do we need any of this ? Do we need more, less, all of the above ? I’d like to avoid using several new tools, but perhaps that’s the way to go ? Did I miss an obvious contender ?

If you’ve been doing any templating with Magnolia, you probably know our tag library (the bits with <cms:). Some of these “tags” are responsible for rendering the “green bars” on your Magnolia pages.

This tag library been around since pre-3.0 times, and somehow has not evolved much since. Over the years, and especially the last, many concepts have been introduced in Magnolia which make large parts of this tag library irrelevant, and too complex, both to maintain and use. Content inheritance and i18n, for instance, are now supported at much higher levels in Magnolia.

Built-in support for different templating languages is also something we’ve introduced a while ago, and have been improving since 4.0; so far, we’ve been lucky that FreeMarker has support for tag libraries (and that contributors have helped improved, too!), but supporting other templating engines has always been a burden with regards to the tag library. Porting it to different languages is something we’ve always put off.

Since Magnolia 4.0, template scripts also have access to a bunch of objects, which make, again, parts of the tag library obsolete.

So, all this, to introduce yet another new feature of Magnolia 4.3. Not one that will make me the most popular kid on the block, but one I’m hoping users, templaters especially, will embrace nonetheless.

Instead of trying to (keep on) patch up the existing tag library, we decided to go ahead and introduce a cleaner, leaner, simpler set of components. We also decided to separate the taglib implementation from the actual ui component rendering. In our eyes, this has several advantages:

• it should be close to trivial to integrate with other templating engines. For an example of how we’ve done it for FreeMarker and JSP, see the info.magnolia.templatinguicomponents.freemarker and info.magnolia.templatinguicomponents.jsp packages.
• it is more testable. Most of the functionality lies in the AuthoringUiComponent implementations, which have no connection whatsoever to the templating engine, i.e all that’s needed to test them is a few Magnolia components (The AggregationState for instance) and an output.
• it is more maintainable. We’ve analyzed the current tag library, and kept things to a bare minimum; we’re looking ahead of us, and thinking about maintaining 100% compatibility with these new components for Magnolia 5.0. The components currently provide a thin layer around existing magnolia-gui components, with “good defaults”. That layer will probably go away or change drastically with Magnolia 5.0, so we’re striving to keep as clean as possible; no random setting of parameters and attributes until things work; we’re trying to avoid some of the magic that’s in the tag library code, and carefully deconstruct and document the current code, in the hope to allow a seamless migration in the future.
• it should be fairly simple to introduce new or custom ui components. If your specific project needs different or more such components, we’re hoping your weapon of choice will be this new API.
• they provide sensible defaults, with less options. Many features or options are not necessary anymore and are really there for historical reasons (think the various nodeCollectionName and associated attributes of the current tag library). See some examples below. Other “features” have been consciously removed; for example, you can’t add buttons in the bar tags, and specify their position. This is the kind of thing that we will probably re-implement once we clearer vision of how this would be working with the 5.0 gui. The positioning of such buttons, for instance, should typically be solved with CSS.
• lastly, they are paving the way for 5.0. By introducing these new components, we’re hoping for a simpler, more transparent upgrade to the future Magnolia 5.0. Surely, they’ll evolve more, but we have been, and will be, working hard on making sure the differences will be as minor as possible. The current (now “old” ) tag library will hopefully still be supported, but more drastic changes to templates might be required when migrating to 5.0.

Before you go and start using those, a note of warning, and a call for help: at the time of writing, the latest implementation is available in Magnolia 4.3 Milestone 2. If you look at the code, you’ll see a lot of TODOs;) We’re hoping to get something more finalized for the next milestone, of course. But we’ll need your feedback.

We’ve tried to cover the “basic” use cases. There are certainly regular use cases we’ve overlooked, and some less regular ones too. For both cases, please voice your opinion here or on the users’ list! We’re hoping to gather enough feedback to 1) cover more of the common use cases, 2) provide or document ways to cover specific and exotic use cases.

Ok, enough rambling, here are a couple of usage samples. These are written with the FreeMarker syntax, and make use of the aforementioned templating support objects, I’ll assume you’re familiar with those.

<!-- a "main bar" using the default label for the dialog defined as the "dialog" property of the current template definition -->
<@ui.main dialog=def.dialog />

<!-- an "edit bar" to edit a different node than the current one, with a specific dialog (if different than the one deduced from the "target" node -->
<@ui.edit target=content.links dialog='extraLinksDialog' />

For JSP equivalents, replace <@ui. with <ui:, and use quotes/EL expressions as appropriate, or have a look at our integration tests. (yes, I’m writing this before committing these tests, but watch this space for news)

A few things that still need to be sorted out:

• i18n is, or should be, assumed for all text properties: any label can be an i18n key. The i18n basename should be appropriately deduced; it’s not clear at the time of writing how. (The current template or paragraph definition, probably, but that’s no so clear for “new bars”, since there’s no current paragraph.)
• the wrapper JSP taglib is incomplete in 4.3 M2.
• various TODOs (mostly clarifying things up)
• we’re thinking about deprecating/replacing a few more tags, such as <cms:includeTemplate, which also has add equivalents since a while, in the form of the render* methods of MagnoliaTemplatingUtilities, which is one the templating support objects.
• your feedback !

Hoping to hear from you soon !

Two weeks ago, we released the first milestone of Magnolia 4.3. Amongst other things (see my team mates’ blogs in the side bar!), we introduced Groovy support. It’s something that’s been done before (most notably by the folks at openmindLAB with their Groovy shell module), but we wanted to take things a few steps further.

I recorded this video (my first attempt at doing so – an experiment, really. Be forgiving) to try and show the basic features.

Now that the 2nd milestone for Magnolia 4.3 has been released, there’s more. Scripts are storable and editable in the repository, amongst other things! Edit your templates, your models (scripts), all from within the browser (or WebDAV), and publish it all, without manipulating jar files. Woohoo.

This new module is available with the Community Edition bundle (see the /add-ons folder). The sources are in the /community/modules section of our Subversion repository, and it’s also available in our public Maven repository. Discuss it on our mailing lists, and report any issue you might have on our issue tracker (patches welcome as always). But most importantly… ENJOY !

Another thing we’ve also started using and sharing recently are mind maps. We need to track work items and their progress in our Scrum sprints, and we’ve realized it works much better for us than the whiteboard/cork board (remoteness problems), or the g–gle spreadsheet we’ve also been using until recently. But we’ve also realized it was a pain in the rear to get burndown charts out of that without manually counting items – which inevitably led to outdated charts.

We’ve been using mind42.com over the last month or so, and it’s worked pretty well, even when editing the map concurrently. We use some of its icons for each of the map items, particularly the “progress” icons, which we use on what would otherwise be story-items; a simple click on the icon increases the progress from 0 to 100% in 25% steps. And those burndown charts ? Ah, well. There’s an export-to-xml function on that thing. So, enter some http headers snooping, curl magic, regular expression fairies, python pixie dust, jquery hoodoo, and voilà !

http://dev.magnolia-cms.com/burndown/

For the curious amongst you (it’s fairly frustrating to talk to a completely impersonal and possibly absent “you”), here are some more details:

• It’s all just one python script that fetches the exported xml (I lied above, I switched back to liburl once I realize I couldn’t install the correct version of pycurl on our server), does some regex magic to pick the interesting info out of the xml (absolutely no need to parse it), stores timestamped data everytime it’s executed, does some not-so-fancy calculations and generates the html page you’ve seen, based a on simple template. (gotta love the %(foobar)s)
• This script is executed by Hudson every 12 hours, once during the night, once just before our scrum meeting, so that we don’t have to worry about updating any charts anymore, nor use our fingers to count the “done” items. Wooh.
• I haven’t done any Javascript wizardry myself, really. All props for the chart are due to the awesome flot library. It’s much more powerful than what we use it for, so if you need charts on your webpages, give it a go! The only downside I’d see to it is that it probably doesn’t degrade very nicely, since the data is in a Javascript array. Some time in the past I saw another charting library that would use data from a <table> element, such that is you didn’t have the necessarily modern browser, you’d still see the data. Granted, you could probably fetch that data from a <table> using jQuery, too !

* Maven 2.0.10 : we now require Maven 2.0.10 to build Magnolia, through the enforcer plugin. Eclipse and IDEA users, rejoice, however, because we’ve made the configuration laxer: regular Maven invocations will require Maven 2.0.10 or a more recent version (which includes Maven 2.1 which Eclipse and IDEA use internally); only when performing a release will the enforcer plugin strictly require Maven 2.0.10.

* If you’ve had Clover license issues recently while attempting to build/release Magnolia, a module or project, rejoice. You now have two options:
1) live with the evaluation license that’s bundled in the Clover Maven plugin itself – this should work for a little while now, as I’ve just updated the pom to use the latest version of Clover.

2) use your own license: the parent pom configures the plugin so that it uses a cloverLicenseLocation property. You can, for instance, define it in your ~/.m2/settings.xml file, using a profile, such as :
 <profiles>
   <profile>
     <id>my-default-profile</id>
     <activation>
       <activeByDefault>true</activeByDefault>
     </activation>
     <properties>
       <cloverLicenseLocation>${user.home}/.m2/clover.license</cloverLicenseLocation>
     </properties>
[...]
Provided that your license key is indeed in ~/.m2/clover.license

If the property isn’t defined in your settings.xml file, the plugin will fall back to the evaluation license. On the other hand, you’ll get an explicit error message if you define the property but make it point to an non-existent or invalid file.

Next step will be to provide a valid license for our open-source projects.

* We now keep track of the parent pom changes in Jira: see http://jira.magnolia-cms.com/browse/BUILD

* Magnolia 4.1 will require Java 1.5, but some modules might still be happy with 1.4, or might want to go ahead and use 1.6: we’ve introduced a ${javaVersion} property. If you want to build your project/module against 1.5, simply add a <javaVersion>1.5</javaVersion> property. The default is still 1.4, so that all modules can update to the new version of the parent pom without breaking compatibility. The main Magnolia project and some modules have this set to 1.5 now. Ideally, we won’t update this property to 1.5 for modules that don’t depend on Magnolia 4.1 yet.

* Projects and modules using the info.magnolia:magnolia-parent-pom-enterprise parent pom will now be deployed to http://repo.magnolia-cms.com/enterprise/. The transition is insured as all relevant other parent poms (-internal and -project) now have both the new /enterprise repo and the old /restricted repo (which shouldn’t be used anymore – contact me if doubts about this)

One final remark: there are still people out there who extend info.magnolia:magnolia-project in their own project. Don’t ! There is no good reason to do so. Likewise, if your project or module is not meant to be hosted here, there’s probably no good reason to use our parent poms (although if you do, please contact me or send a mail to the users list, I’d like to hear about it). What you want to do is probably build a project that *depends* on Magnolia. If you’re building a webapp with Maven (<packaging>war</packaging>), here’s an (outdated) example of how to do it: http://svn.magnolia-cms.com/view/community/modules/magnolia-webapp-documentation/trunk/pom.xml?revision=19481&view=markup If you are buliding a module, just have a look at any of the up-to-date modules under http://svn.magnolia-cms.com/view/community/modules

Until next time,

With this simple command, it just worked (using the webapps of our latest 4.0 Milestone 2, as deployed in our current standard Tomcat-based bundle)

java -jar winstone-0.9.10.jar --useJasper --webappsDir=/Applications/MagnoliaEnterpriseEdition/apache-tomcat-5.5.27/webapps/

All that was needed is to have the following in a lib folder:
./lib
./lib/commons-logging-api-1.1.1.jar
./lib/jasper-compiler-jdt.jar
./lib/jasper-compiler.jar
./lib/jasper-runtime.jar
./lib/jsp-api.jar

(which sadly adds 1.9mb to Winstone’s meager 300k)

A warning about tools.jar not being found can be safely ignored on OSX, at least if you have the developer tools installed.

Two worries left: 1) the JAAS configuration. I’m not sure if it’s handled properly. Magnolia itself needs improvement in this area anyway. 2) Performance. The performance in AdminCentral seems okayish, but browsing the demo site is utterly slow. It seems as slow as when Tomcat compiles JSPs… however there are no JSPs in these pages! Taglibs are used in FreeMarker templates, but we got rid of performance issues in that area ages ago, at least with Tomcat…

What’s next ? I’d love to see a clickable embedded version of Magnolia. With, say, a minimal Swing GUI or a CLI which would ask me what port I want to start it on, if I want to run an author or public instance, and if applicable, where the associated public instance is.

One, we’re finally getting rid of a bunch of old “stuff” in Magnolia’s main codebase. A very welcome diet, as some of that code has been lying around unused or deprecated for two years or more. It’s also a relief to see that this will incidentally increase our code coverage and/or help making some classes a little more testable. There’s still a long way to go in that area though !

Second, we’re moving a bunch of modules, which have been nurtured internally, to the community space. Watch out for

• In place templating – yes! You’ll be able to edit (Freemarker) templates directly from inside Magnolia ! Support for JSP isn’t impossible, but involved some much hassle (JSPs have to be on the file system) that we decided to leave that as an exercise for the reader. I’m pretty convinced everyone will love the Freemarker support we’ve introduced though. It takes a bit getting used to, but once you get the hang of it, it’s so much cleaner than JSP… <insert bad-taste pun about never coming back>.
• Resources – a simple module that allows one to handle web resources in a separate workspace and within Magnolia. CSS is currently supported, we’re hoping to add support for Javascript and images soonish, making this a one-stop shop for all your layout/design resources.
• Form – build simple forms within Magnolia, and process them. Elegant css-based layout for your forms, a simple API for processing the results.
• Webdav support – still experimental, but we’re hoping to get this to work for DMS, templates, and so on.

So, without further ado, if you have to suffer, but are no masochist, it’s a simple as that: http://www.kronenberg.org/ies4osx/ !

Unfortunately, their main site (codepress.org) seems down at the moment, and the Google-cached changelog page seems to tell me there’s been no release since a year. Does anybody what the real status is and/or is there’s any alternative ?

Quick update – this is available since Magnolia 4.2, thanks to Federico ! See http://documentation.magnolia-cms.com/reference/dialogs/controls.html#CodeEditorControl for details.

It all started with a long standing need to restructure our Subversion repository, along with a desire to improve our Maven pom files. Both tasks were a bit daunting at first, but at some point, after long egg and chicken debates, it just became too itchy and I got started.

• The Subversion repository structure has been completely overhauled. It’s now much easier to navigate AND to maintain. It is even documented !
• Checkout helper scripts have been unified and overhauled. Check ‘em ! Documentation above.
• Pom files have been overhauled too. Here’s a quick diagram of their structure.
• All poms inherit from a common parent which define a bunch of generic properties, plugins, and dependencies. Everything can be overridden, but it provides a stable basis.
• The lower level of parent poms (magnolia-parent-pom-community-module and so on) share a common site descriptor and skin (provided by magnolia-parent-pom-abstract) and provide the specific repositories and deployment locations.
• Thanks to the above, projects extending these poms now deploy their artifacts and sites in different locations without any hassle.
• Javadoc is now generated in both aggregated and non-aggregated forms ! This means that on the main Maven generated website, you can find aggregated Javadoc (includes Javadoc for all sub-modules) and non-aggregated Javadoc (Javadoc for a single module)
• All our projects now include a Clover report. (Which hopefully will become greener!)
• Archetypes for easily generating skeletons for Magnolia-based projects and modules are being overhauled as well !
• Our Maven repository should soon be synchronized with the central Maven repository. Follow MAVENUPLOAD-2194 and SYS-19 to be updated on this ! For starters, we might only have our parent poms synchronized, but that should be enough to be able to build any Magnolia module without struggling with pom inheritance.