Greg’s ramblings

Still looking for “the” perfect forum software

Monday, June 14th, 2010 | 2 Comments

Since a couple of weeks, I’ve been looking, on-and-off, for “the” perfect forum software. The Magnolia community needs a (new, better) platform. At the moment, we’re relying on a wiki (good for draft documents, not so much for discussions), an issue tracker (again, good for tracking bugs and work progress, not so much for discussions), and a mailing-list; we have two mailing-lists: the developers mailing list, which is flooded with notification traffic, and the users list, which is gaining some traffic since the last few months. That extra traffic is a good thing (more users, more interest, more help and more feedback!) but can also drive some people away. (they’re not necessarily interested in getting emails from the Magnolia community all the time)

› Continue reading

Paving the way for 5.0 – new, refreshed, authoring tags for templates

Friday, February 19th, 2010 | 6 Comments

Update (2010-03-30): I finally revamped the “concept” page on the wiki, and it should now be up-to-date (more than this post), and provide some more insight on what’s next.

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.

› Continue reading

Tags: magnolia templating

Magnolia & Groovy

Friday, February 19th, 2010 | 1 Comment

Oh, the bad puns one could make in the title of such an article.

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 !

Tags: 4.3, groovy, magnolia

Going agile, one burndown chart at a time

Friday, January 29th, 2010 | 3 Comments

It’s been a while now (since I’ve posted here, yes, but that isn’t my point) that we’re undertaking agilizing our development practices at Magnolia. (yes, I make up words. It’s friday.) Every now and then, we’ll try something new. It’s always a challenge, since we can’t even do stand-up meetings (given that 25% of our small team is in another corner of Europe). One of the latest things we’ve started using is… a webcam; so that we can actually use a whiteboard, for instance, and have it visible by the whole team. It’s one of those fancy gadgets which you can rotate and zoom remotely. The little noise it makes when it turns its head towards you is a little creepy. And I’m not sure I’m ready to share these images with the world just yet. Which is a good thing, because that wasn’t the point of this article, at all.

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 !

Build updates

Tuesday, June 2nd, 2009 | No Comments

A recent release of our parent poms, v9, introduces the following changes and improvements:

* 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,

Winstoned !

Tuesday, December 23rd, 2008 | No Comments

I’m happy to report that Magnolia seemingly works in Winstone !

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.

Tags: build

Growing and shrinking

Wednesday, December 10th, 2008 | No Comments

Two exciting things happening at once !

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.

Tags: code, modules, templating

IE6 on OSX

Wednesday, October 22nd, 2008 | No Comments

Yes, some people still have to go through the pain of using Internet Explorer … 6. Tonight, that’s me. After loosing (too much) time getting a virtual machine or a remote desktop to a windows machine, and then on said machine getting an IE6 to actually work (Multiple_IE never really worked for me, and Microsoft’s 400mb of disk image for doing the same with a single version of IE is still downloading…), I stumbled accross Darwine (Wine for OSX) and … yes, IEs4osx.

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

Tags: software

Codepress for Magnolia ?

Tuesday, October 7th, 2008 | 12 Comments

I was looking for a simple way to get line numbers in html textareas – amongst other things to edit css, javascript and templates from within Magnolia, making my whole layout activatable/versionable ! – and I just stumbled upon Codepress ! Man, that thing is sweet ! (if you use Firefox, that is)

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.

Tags: templating

News from Bob !

Thursday, September 4th, 2008 | No Comments

There has been some definitive construction work undergoing at Magnolia in the last few days, and this is what this post is all about: changes and improvements in our builds ! (Bob the Builder, geddit?)

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. › Continue reading

Tags: build